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

Steven Peters via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 4 12:42:27 PDT 2017 

Wow, thanks Jonas! I guess that settles it if it is fixed already.

Regards,
Steve

On Wed, Oct 4, 2017 at 11:08 AM, Jonas Devlieghere <jdevlieghere at apple.com>
wrote:

> Hi Steve,
>
> I had a quick look and with the help of creduce I was able to reproduce
> this with https://reviews.llvm.org/P8041
>
> It looks like this is already fixed upstream and in the swift-4.1-branch.
>
> Cheers,
> Jonas
>
>
> On Oct 4, 2017, at 9:40 AM, mats petersson via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> The size of the source is not in itself indicative of the overall
> complexity [or simplicity, as I believe large basic-blocks is the main
> culprit due to something along the lines of "for each instruction I in BB {
> for each instruction J (except I) in BB { do something } }"] - it's easy to
> produce long sequences with for example a simple macro that repeats some
> code.
>
> However, 40 minutes is rather a long time, so I'd say you probably have a
> hang.
>
> --
> Mats
>
> On 3 October 2017 at 20:22, Steven Peters <scpeters at openrobotics.org>
> wrote:
>
>> Mats,
>>
>> That's a good point. I can't prove it's an infinite loop. Compiling with
>> `-O1` or `-march=native` allows it to complete in less than 0.2 seconds
>> with an object file size of 12 kB. I just tested the problematic case again
>> and let it go for 40 minutes before I stopped it. I'll try running it a
>> little longer on a computer I don't need to use, but it's not guaranteed to
>> fix it I guess.
>>
>> It's tough to instrospect without debug symbols in the compiler toolchain.
>>
>> Steve
>>
>> On Tue, Oct 3, 2017 at 3:17 AM, mats petersson <mats at planetcatfish.com>
>> wrote:
>>
>>> 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::MachineFunctionPas
>>>> s::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::ExecuteCompilerIn
>>>> vocation(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
>>>>
>>>>
>>>
>>
> _______________________________________________
> 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/20171004/8f3db35e/attachment.html>

More information about the cfe-dev mailing list