Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10627 closed bug (fixed)

Regression: cabal install of numeric-prelude hangs

Reported by: George Owned by:
Priority: high Milestone: 7.10.2
Component: Compiler Version: 7.10.2-rc2
Keywords: Cc: ghc@…, george
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case: simplCore/should_compile/T10627
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by George)

While trying to do cabal install species with HP 7.10.2rc2 I discovered that it hangs compiling numeric-prelude in src/Algebra/RealRing.h. It doesn't seem to be busy computing as cpu usage is 0%. It also hangs with HP 7.10.1.20150612 but works with HP 7.10.1.20150601

ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150630
cabal install --verbose=3 numeric-prelude
...
[39 of 97] Compiling Algebra.RealRing ( src/Algebra/RealRing.hs, dist/build/Algebra/RealRing.o )
...

Result size of Float out(FOS {Lam = Just 0,
                              Consts = True,
                              OverSatApps = True})
  = {terms: 3,506, types: 3,224, coercions: 4}
*** Common sub-expression:
Result size of Common sub-expression

Attachments (1)

RealRing.hs (253 bytes) - added by Lemming 4 years ago.
minimal example making the compiler hang

Download all attachments as: .zip

Change History (25)

comment:1 Changed 4 years ago by thomie

Did you try installing the same version of numeric-prelude with ghc-7.10.1. As in: is this a regression?

comment:2 Changed 4 years ago by George

Description: modified (diff)
Summary: cabal install of numeric-prelude hangsRegression: cabal install of numeric-prelude hangs

comment:3 in reply to:  1 Changed 4 years ago by George

Replying to thomie:

Did you try installing the same version of numeric-prelude with ghc-7.10.1. As in: is this a regression?

Thanks for asking me to check that, it is a regression as noted in the description which I just modified. In all cases the version of numeric-prelude is 0.4.2

Last edited 4 years ago by George (previous) (diff)

comment:4 Changed 4 years ago by thomie

Ok. The next thing to do would be to reduce the test. No packages, no cabal, just a single file that fails to build with ghc. Sometimes this is not so easy, but without it these type of bugs don't get fixed easily either. Maybe you want to give it a try?

comment:5 Changed 4 years ago by George

Sorry, I don't think I can, I will however send mail to the package maintainer, Henning Thielemann and cc Brent Yorgey whose species package depends on numeric prelude. I set the priority as high as it seems that shipping a release that can't compile a package it could previously is not a good thing. The impact of the bug is not clear. However, I personally don't need this fix.

Also it would be good if somebody could verify that this fails on 7.10.2 HEAD and if it fails on other platforms, i.e. is this bug specific to the Mac platform?

Last edited 4 years ago by George (previous) (diff)

comment:6 Changed 4 years ago by Lemming

My first interesting observation is that GHCi (run by cabal repl) can load all modules.

comment:7 Changed 4 years ago by Lemming

Cc: ghc@… added

comment:8 in reply to:  6 ; Changed 4 years ago by George

Replying to Lemming:

My first interesting observation is that GHCi (run by cabal repl) can load all modules.

Thanks Lemming, what version of ghc are you using? What platform?

comment:9 in reply to:  8 ; Changed 4 years ago by Lemming

Replying to George:

Thanks Lemming, what version of ghc are you using? What platform?

GHC-7.10.1.20150630 from the Ubuntu-HVR-PPA package ghc-7.10.2

comment:10 in reply to:  9 Changed 4 years ago by George

Replying to Lemming:

Replying to George:

Thanks Lemming, what version of ghc are you using? What platform?

GHC-7.10.1.20150630 from the Ubuntu-HVR-PPA package ghc-7.10.2

Can you confirm that you can reproduce the bug with cabal install?

Changed 4 years ago by Lemming

Attachment: RealRing.hs added

minimal example making the compiler hang

comment:11 Changed 4 years ago by Lemming

I attached a minimal example that you can run with:

$ ghc-7.10.1.20150630 -O RealRing.hs
[1 of 1] Compiling RealRing         ( RealRing.hs, RealRing.o )

RealRing.hs:11:6: Warning:
    Rule "NP.roundSimple :: a -> Word" may never fire
      because ‘roundSimple’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘roundSimple’
^C

comment:12 in reply to:  6 Changed 4 years ago by George

Replying to Lemming:

My first interesting observation is that GHCi (run by cabal repl) can load all modules.

Yes, cabal repl works for me also

ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150630
cabal get -s numeric-prelude
cd numeric-prelude
cabal sandbox init
cabal install --only-dependencies 
cabal repl

However after quitting out of the repl, cabal build fails cabal build Building numeric-prelude-0.4.2... ... It hangs after emitting the following

src/Algebra/RealRing.hs:369:6: Warning:
    Rule "NP.roundSimple :: a -> Word64" may never fire
      because ‘roundSimple’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘roundSimple’

comment:13 in reply to:  6 Changed 4 years ago by Lemming

Replying to Lemming:

My first interesting observation is that GHCi (run by cabal repl) can load all modules.

I think it is because GHCi does not optimize and the problem seems to be the rewrite rule.

comment:14 in reply to:  11 Changed 4 years ago by George

Replying to Lemming:

I attached a minimal example that you can run with:

$ ghc-7.10.1.20150630 -O RealRing.hs
[1 of 1] Compiling RealRing         ( RealRing.hs, RealRing.o )

RealRing.hs:11:6: Warning:
    Rule "NP.roundSimple :: a -> Word" may never fire
      because ‘roundSimple’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘roundSimple’
^C

Thanks! That fails for me also. It works if I compile without the -O

comment:15 Changed 4 years ago by George

Cc: george added
Operating System: MacOS XUnknown/Multiple

comment:16 Changed 4 years ago by simonpj

Cc: ghc@… george removed
Operating System: Unknown/MultipleMacOS X

Amazing. I couldn't resist looking at this, and it seems to be a very long-standing bug, introduced I think by

commit 30c17e7096919c55218083c8fcb98e6287552058
Author: simonpj@microsoft.com <unknown>
Date:   Thu Nov 25 17:23:56 2010 +0000

    Substitution should just substitute, not optimise
    
    This was causing Trac #4524, by optimising
         (e |> co)  to   e
    on the LHS of a rule.  Result, the template variable
    'co' wasn't bound any more.
    
    Now that substition doesn't optimise, it seems sensible to call
    simpleOptExpr rather than substExpr when substituting in the
    RHS of rules.  Not a big deal either way.

The last para says "optimise the RHS of rules when substituting", but that is too strict in the IdInfo of an Id if the RULE refers to the same Id.

I don't know how this ever worked. Patch coming.

Simon

comment:17 Changed 4 years ago by Lemming

Cc: ghc@… george added
Operating System: MacOS XUnknown/Multiple

comment:18 Changed 4 years ago by Simon Peyton Jones <simonpj@…>

In d073c770209d3e7208059b3be8187a47c9181a3e/ghc:

Do not optimise RULE lhs in substRule

This was causing Trac #10627.
See Note [Substitute lazily] in CoreSubst.

The bug was introduced by
   commit 30c17e7096919c55218083c8fcb98e6287552058
    Author: simonpj@microsoft.com <unknown>
    Date:   Thu Nov 25 17:23:56 2010 +0000
    Substitution should just substitute, not optimise

The fix is not to optimise the RHS as well as not-optimising the LHS!
The simplifier does the right thing in Simplify.simplRule

comment:19 Changed 4 years ago by simonpj

Status: newmerge
Test Case: simplCore/should_compile/T10627

OK, fixed now. Thanks for reporting.

Worth merging to 7.10.2

Simon

comment:20 Changed 4 years ago by George

That's great! Do we understand why this worked as recently as June 1st? Also, why would the compiler hang (not loop infinitely) without this fix? Just curious.

This seems to be the relevant backtrace for the hanging problem before the fix:

Thread 3:
0   libsystem_kernel.dylib            0x00007fff8bac6136 __psynch_cvwait + 10
1   libHSrts_thr-ghc7.10.1.20150630.dylib    0x0000000106894d16 waitCondition + 6
2   libHSrts_thr-ghc7.10.1.20150630.dylib    0x0000000106869f63 yieldCapability + 419
3   libHSrts_thr-ghc7.10.1.20150630.dylib    0x000000010687c3c6 schedule + 502
4   libHSrts_thr-ghc7.10.1.20150630.dylib    0x000000010687ce5d scheduleWorker + 13
5   libsystem_pthread.dylib           0x00007fff8c97f268 _pthread_body + 131
6   libsystem_pthread.dylib           0x00007fff8c97f1e5 _pthread_start + 176
7   libsystem_pthread.dylib           0x00007fff8c97d41d thread_start + 13

Thanks

Last edited 4 years ago by George (previous) (diff)

comment:21 in reply to:  20 Changed 4 years ago by simonpj

Replying to George:

Do we understand why this worked as recently as June 1st?

No, I'm not sure.

Also, why would the compiler hang without this fix? Just curious.

It's the knot-tying in CoreSubst.simplRecBndrs. Did you read Note [Substitute lazily] referred to in the commit message?

comment:22 Changed 4 years ago by George

Yes, in between posting the comment and reading your reply. :) Thanks for explaining! Sorry to bother you.

comment:23 Changed 4 years ago by bgamari

Resolution: fixed
Status: mergeclosed

Merged into ghc-7.10 as 3794b597896e1138e23043de5646e60e3d011b27.

comment:24 Changed 4 years ago by Lemming

I can compile numeric-prelude with ghc-7.10.1.20150715.

Note: See TracTickets for help on using tickets.