Opened 14 months ago

Last modified 10 months ago

#7694 new bug

LLVM: bootstrapping with LLVM 3.2 does not work

Reported by: gmainland Owned by: dterei
Priority: normal Milestone: 7.8.3
Component: Compiler (LLVM) Version: 7.7
Keywords: Cc: carter.schonwald@…, jan.stolarek@…
Operating System: Unknown/Multiple Architecture: x86_64 (amd64)
Type of failure: Building GHC failed Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Change History (14)

comment:1 Changed 12 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1
  • Owner set to dterei

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

David, do you know what's going on?

comment:2 Changed 12 months ago by dterei

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

comment:3 Changed 12 months ago by dterei

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.

comment:4 Changed 12 months ago by carter

  • Cc carter.schonwald@… added

comment:5 Changed 10 months ago by gmainland

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?

comment:6 Changed 10 months ago by dterei

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

comment:7 Changed 10 months ago by gmainland

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?

comment:8 Changed 10 months ago by jstolarek

  • Cc jan.stolarek@… added

comment:9 Changed 10 months ago by dterei

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.

comment:10 follow-up: Changed 10 months ago by c00w

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

comment:11 in reply to: ↑ 10 Changed 10 months ago by dterei

Replying to 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.

comment:12 Changed 10 months ago by c00w

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.

comment:13 Changed 10 months ago by carter

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 )

comment:14 Changed 10 months ago by c00w

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.

Note: See TracTickets for help on using tickets.