How to report bug when compiler hangs

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

How to report bug when compiler hangs

Eric Fiselier via cfe-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
I just realized that I was mistaken that `-vectorize-loops` was the source of the problem. My broader question still stands.

Regards,
Steve Peters

On Thu, Sep 28, 2017 at 1:03 PM, Steven Peters <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
In reply to this post by Eric Fiselier via cfe-dev
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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
In reply to this post by Eric Fiselier via cfe-dev
On Thu, Sep 28, 2017 at 01:03:12PM -0700, Steven Peters via cfe-dev wrote:
> 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.

Run the failing command with -save-temps, so that the preprocessed
source can be used to reproduce it. Double check that it fails with
upstream clang. If yes, submit a PR and attach the preprocessed source
together with any special flags needed to trigger it.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
In reply to this post by Eric Fiselier via cfe-dev
Thanks for the idea. It looks like another infinite loop in DAG Combine (like r206873 and 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 <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
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 <[hidden email]> wrote:
Thanks for the idea. It looks like another infinite loop in DAG Combine (like r206873 and 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 <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
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 <[hidden email]> 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 <[hidden email]> wrote:
Thanks for the idea. It looks like another infinite loop in DAG Combine (like r206873 and 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 <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Thanks for the idea. It looks like another infinite loop in DAG Combine (like r206873 and 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 <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev





_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Thanks for the idea. It looks like another infinite loop in DAG Combine (like r206873 and 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 <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Thanks for the idea. It looks like another infinite loop in DAG Combine (like r206873 and 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 <[hidden email]> 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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev
Was it actually fixed, or did the symptoms go away because of other changes?


Jon

On 10/4/17 1:42 PM, Steven Peters via cfe-dev wrote:

> 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
> <[hidden email] <mailto:[hidden email]>> 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
>
>

--
Jon Roelofs
[hidden email]
CodeSourcery / Mentor Embedded / Siemens
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to report bug when compiler hangs

Eric Fiselier via cfe-dev

> On Oct 4, 2017, at 8:46 PM, Jonathan Roelofs <[hidden email]> wrote:
>
> Was it actually fixed, or did the symptoms go away because of other changes?

+Volodymyr bisected this and found that the problem was first hidden by r296898 and actually fixed in r297833: [X86][SSE] Fixed shuffle MOVSS/MOVSD combining of all zeroable inputs

>
>
> Jon
>
> On 10/4/17 1:42 PM, Steven Peters via cfe-dev wrote:
>> 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 <[hidden email] <mailto:[hidden email]>> 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
>
> --
> Jon Roelofs
> [hidden email]
> CodeSourcery / Mentor Embedded / Siemens

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev