How to report bug when compiler hangs


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:

I just realized that I was mistaken that -vectorize-loops was the source of the problem. My broader question still stands.


Steve Peters

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

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.


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:

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.


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.


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.

Hi Steve,

I had a quick look and with the help of creduce I was able to reproduce this with

It looks like this is already fixed upstream and in the swift-4.1-branch.


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



Was it actually fixed, or did the symptoms go away because of other changes?


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