LLVM: bootstrapping with LLVM 3.2 does not work

Building GHC itself using the LLVM back end no longer works with LLVM 3.2 (3.1 is fine). On Linux x86_64, the stage2 compiler fails for me. Unfortunately running the test suite with stage=1 did not produce any quality failures that would help us track down the problem. This does not appear to be related to the new codegen since using LLVM 3.1 does not cause a failure.

Trac metadata

Trac field	Value
Version	7.7
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (LLVM)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added LLVM backend Tbug Trac import labels

changed milestone to %7.8.1

assigned to @trac-dterei

Thanks for the report. Could you paste the problem that you are seeing please?

David, do you know what's going on?

No. I thought I'd fixed 3.2 issues but I'll try bootstrapping myself now to see.

OK I can confirm but not sure of the cause as of yet. This kind of bug may take me a while with the limited time I have available going forward. Usually the issue is in comping hand written Cmm files when the problem is bootstrapping LLVM and no bugs fail in the test suite.

mentioned in issue #7885 (closed)

LLVM 3.3 rc3 now works with a small patch that I pushed to HEAD, so it appears that the problem is only with LLVM 3.2. Should we just blacklist 3.2?

Yes. Bootstrapping with LLVM isn't common at all so blacklisting seems fine to me. Thanks for getting 3.3 working.

I was actually considering blacklisting LLVM 3.2 completely since it clearly is generating bad code *somewhere*. Or at least outputting a warning. How would you feel about that?

I'd be fine with a warning but not outright blacklisting. LLVM 3.2 passes the testsuite fine and so it is very likely the bug only occurs when compiling the hand written Cmm files that can be quite different from the rest of the code GHC produces.

I've been getting incorrect binaries built with 3.2 which are producing:

Illegal instruction (core dumped).

I was never able to get a reduced test case for it, but I have a working ,albeit large, one. This may suggest that you should just blacklist 3.2

Replying to [ticket:7694#comment:71975 c00w]:

I've been getting incorrect binaries built with 3.2 which are producing:

Illegal instruction (core dumped).

Interesting. We haven't had any reports of this so I assumed it was all OK. Can you confirm it works fine with LLVM 3.1 and 3.3?

I was never able to get a reduced test case for it, but I have a working ,albeit large, one. This may suggest that you should just blacklist 3.2

Yes, simply blacklisting 3.2 sounds fine then.

It worked with 3.3 and 2.9, I have not tested with 3.1, will do tomorrow when I have time.

For reference using the deployment configuration of: https://github.com/c00w/BitToll on commit f7869ca produces the segfaults with version 3.2.

I wasn't having problems with llvm aside from when I tried to build ghc via -fllvm with 3.2.

having a warning saying "llvm 3.2 has known issues with ghc, use at your own risk and please consider using 3.3 instead" or something like that would be better.

@c00w, whats the full commit hash? the short hash doesnt make it possible to look up the commit (or at least i don't know how to )

Full commit hash is f7869ca8bd3742249f46b60d3d34c8f8ba26a3c2.

Note that its broken from that commit minus three to three after that where I removed the llvm building. The failure is coming from the APIServer.hs file in the haskell directory. Every attempt to make a smaller example removed the crash. If you want to actually reproduce the crash, rename the hostname in the VagrantFile to atlantis.m.bittoll.com and then make test should bring up a virtual machine. There is a dependency installation script in dev.

closed

I think this is pretty much a WONTFIX.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

removed milestone

mentioned in issue #9391 (closed)

added ghc build failure label

added Pnormal label