Opened 3 years ago

Closed 16 months ago

Last modified 16 months ago

#7694 closed bug (wontfix)

LLVM: bootstrapping with LLVM 3.2 does not work

Reported by: gmainland Owned by: dterei
Priority: normal Milestone:
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 Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

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 (16)

comment:1 Changed 2 years 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 2 years ago by dterei

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

comment:3 Changed 2 years 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 2 years ago by carter

  • Cc carter.schonwald@… added

comment:5 Changed 2 years 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 2 years 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 2 years 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 2 years ago by jstolarek

  • Cc jan.stolarek@… added

comment:9 Changed 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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.

comment:15 Changed 16 months ago by thoughtpolice

  • Resolution set to wontfix
  • Status changed from new to closed

I think this is pretty much a WONTFIX.

comment:16 Changed 16 months ago by thoughtpolice

  • Milestone 7.8.3 deleted
Note: See TracTickets for help on using tickets.