[cfe-dev] How to report bug when compiler hangs

mats petersson via cfe-dev cfe-dev at lists.llvm.org
Tue Oct 3 03:17:44 PDT 2017


Are you absolutely sure it hangs, and not just "taking a very long time"?
I've hit the O(n^2) type problem with instruction selection, so if you have
some code that produces very long basic-blocks, it could take ages to
compile them - and the call-stack in that case will look very much like the
one you posted.

I'm not saying you that your case isn't a genuine bug, I'm just asking so
that the "right" problem is reported.

--
Mats

On 2 October 2017 at 21:03, Steven Peters via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Thanks for the idea. It looks like another infinite loop in DAG Combine
> (like r206873
> <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140421/213744.html>
> and D26605 <https://reviews.llvm.org/D26605>) when I compile that file
> with -O2 and for the core2 target cpu. Is there any advice on introspecting
> SelectionDAG? I'm not sure how to identify which part of the source code is
> triggering the infinite loop.
>
> example stacktrace:
> ~~~
> (lldb) thread backtrace all
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x00000001079c39d1 clang`llvm::SelectionDAG::Combine(llvm::CombineLevel,
> llvm::AAResults&, llvm::CodeGenOpt::Level) + 1441
>     frame #1: 0x00000001079c242e clang`llvm::SelectionDAGISel::CodeGenAndEmitDAG()
> + 974
>     frame #2: 0x000000010790f726 clang`llvm::SelectionDAGISel::
> SelectAllBasicBlocks(llvm::Function const&) + 6118
>     frame #3: 0x0000000107907846 clang`llvm::SelectionDAGISel::
> runOnMachineFunction(llvm::MachineFunction&) + 998
>     frame #4: 0x000000010829cd54 clang`(anonymous
> namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
> + 20
>     frame #5: 0x000000010790590d clang`llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
> + 125
>     frame #6: 0x00000001078c2562 clang`llvm::FPPassManager::runOnFunction(llvm::Function&)
> + 498
>     frame #7: 0x00000001078eb943 clang`llvm::FPPassManager::runOnModule(llvm::Module&)
> + 67
>     frame #8: 0x00000001078c67f5 clang`llvm::legacy::
> PassManagerImpl::run(llvm::Module&) + 693
>     frame #9: 0x000000010789e09c clang`clang::EmitBackendOutput(clang::DiagnosticsEngine&,
> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
> const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream,
> std::__1::default_delete<llvm::raw_pwrite_stream> >) + 2700
>     frame #10: 0x000000010786f00a clang`clang::BackendConsumer::
> HandleTranslationUnit(clang::ASTContext&) + 410
>     frame #11: 0x000000010754b249 clang`clang::ParseAST(clang::Sema&,
> bool, bool) + 249
>     frame #12: 0x00000001075482bc clang`clang::FrontendAction::Execute()
> + 44
>     frame #13: 0x00000001074fe666 clang`clang::CompilerInstance:
> :ExecuteAction(clang::FrontendAction&) + 294
>     frame #14: 0x00000001074fc7b9 clang`clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
> + 2329
>     frame #15: 0x00000001074c6974 clang`cc1_main(llvm::ArrayRef<char
> const*>, char const*, void*) + 1492
>     frame #16: 0x00000001074c24ac clang`main + 13820
>     frame #17: 0x00007fff6206b145 libdyld.dylib`start + 1
>     frame #18: 0x00007fff6206b145 libdyld.dylib`start + 1
> ~~~
>
> Regards,
> Steve
>
> On Fri, Sep 29, 2017 at 12:57 AM, Csaba Raduly <rcsaba at gmail.com> wrote:
>
>> Hi Steven,
>>
>> If the compiler hangs, try to attach the debugger (gdb --pid). You
>> should be able to get a stack trace, which would carry more
>> information.
>>
>> On Thu, Sep 28, 2017 at 10:03 PM, Steven Peters via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> > Hello,
>> >
>> > I've been digging into a compilation problem using the version of clang
>> > distrubuted with XCode 9 on macOS High Sierra. I narrowed the problem
>> down
>> > to the transition from `-O1` to `-O2` for a target cpu of core2, and
>> then I
>> > further narrowed it down to the `-vectorize-loops` option for clang. The
>> > challenge is that this problem manifests with clang failing to
>> terminate. I
>> > don't know if it's a deadlock or getting stuck in an infinite loop, but
>> I
>> > didn't see any guidance in the support documents about how to submit a
>> bug
>> > report in a case like this.
>> >
>> > Current discussion of the compilation failure:
>> > https://github.com/bulletphysics/bullet3/issues/1347
>> >
>> > ~~~
>> > $ cc --version
>> > Apple LLVM version 9.0.0 (clang-900.0.37)
>> > Target: x86_64-apple-darwin17.0.0
>> > Thread model: posix
>> > InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>> > ~~~
>> >
>> > Thanks for your time.
>> >
>> > Regards,
>> > Steve Peters
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>>
>>
>>
>> --
>> GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
>> The Tao of math: The numbers you can count are not the real numbers.
>> Life is complex, with real and imaginary parts.
>> "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus
>> Torvalds
>> "People disagree with me. I just ignore them." -- Linus Torvalds
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171003/64789e32/attachment.html>


More information about the cfe-dev mailing list