Opened 14 months ago

Closed 7 months ago

#8836 closed bug (fixed)

ghc 7.6.3 and 7.4.2 hang on -O2

Reported by: tsuraan Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC doesn't work at all Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

I haven't had any luck finding a minimal test case for this, but the following replicates the issue on my two Linux machines running ghc 7.6.3:

git clone https://github.com/tsuraan/optimal-blocks
cd optimal-blocks
git checkout bceee69f9f03d2e559f96cdf58412ada09c96a8c
cabal sandbox init
cabal install --only-dependencies
cabal configure
cabal build

Cabal build will successfully build Algorithm.OptimalBlocks.SipHash and Algorithm.OptimalBlocks.BuzzHash, and it will attempt to build Algorithm.OptimalBlocks, but it will hang forever, using 100% of a single core. I have no idea how to debug this, but in src/Algorithm/OptimalBlocks.hs, if you replace the "in Blocks (reverse rlist) end" with "in Blocks [] bs", it will compile. Also, if that same file starts with the line "{-# OPTIONS_GHC -O1 #-}" it will compile.

This also happens on my Mac running OSX 10.8.5 and ghc 7.4.2 without llvm; I have to tweak the .cabal file a little to drop the lower bound on base and to get rid of the "-fllvm" flag, but if I do that I see the exact same behaviour.

Change History (9)

comment:1 Changed 14 months ago by tsuraan

  • Summary changed from ghc 7.6.3 (Linux) hangs on -O2 to ghc 7.6.3 and 7.4.2 hang on -O2

comment:2 Changed 14 months ago by gelisam

I can reproduce the issue with 7.6.3 (removing the -fllvm flag), but not with 7.8.20140130 (also removing the upper bound on base). Must have been fixed already.

comment:3 Changed 14 months ago by thoughtpolice

This looks similar to #7944 and #5550 - can you see where the compiler halts during compilation using -v3 or something?

In any case, if it's fixed by 7.8, all the better.

comment:4 Changed 14 months ago by gelisam

You are right, it hangs at the same spot as #7944:

...
*** SpecConstr:
Result size of SpecConstr

comment:5 Changed 14 months ago by thoughtpolice

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

Right, then we know what's wrong. Unfortunately, there isn't really a good 'fix' that's possible to backport to fix SpecConstr for 7.6 users - in the mean time, you'll have to get by with -O1 or (-O2 -fno-spec-constr, I suppose). Alternatively, you can also try tuning the constructor specialisation threshold as noted in #7944.

There won't be a 7.6.4 release, and as this is fixed in HEAD, I'm marking this as a duplicate.

comment:6 Changed 8 months ago by simonpj

  • Resolution duplicate deleted
  • Status changed from closed to new

I believe this is finally fixed; see #8852. Can you try now, with HEAD?

Simon

comment:7 Changed 8 months ago by simonpj

  • Status changed from new to infoneeded

comment:8 Changed 7 months ago by thoughtpolice

I believe this is fixed in HEAD after a quick attempt.

comment:9 Changed 7 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from infoneeded to closed
Note: See TracTickets for help on using tickets.