GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:06:36Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2840Top level string literals2019-07-07T19:06:36ZSimon Peyton JonesTop level string literalsAt the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so. But consider this:
```hs
f :: Int -> String
f n = let a::Addr# = "foo"
in let g y = ...a...g...
...At the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so. But consider this:
```hs
f :: Int -> String
f n = let a::Addr# = "foo"
in let g y = ...a...g...
in g n
```
Here we'd like to float the definitions out thus:
```hs
a::Addr# = "foo"
g y = ...a...g...
f n = g n
```
This is much better. Usually this happens, but not here, because we don't allow a top-level binding for an `Addr#`. But really perhaps we should allow an exception for *literals*, which can safely be bound at top level.
For literals other than strings, this doesn't make any difference, because we inline them freely. But for literal strings we don't want to make lots of copies of them; on the contrary we'd like to CSE identical strings. So it'd help to be able to bind them at top level.
Simon7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/2839Integer not documented in latest docs2019-07-07T19:06:37ZToRAInteger not documented in latest docsThe haddock documentation on the website for Integer is missing, which causes e.g.
- [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html)
- [h...The haddock documentation on the website for Integer is missing, which causes e.g.
- [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html)
- [http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/base/Prelude.html](http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/base/Prelude.html)
- [http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/Prelude.html](http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/Prelude.html)
to not link to it.
nominolo suggested that it's due to the new integer-gmp package not being haddocked with everything else by a bothttps://gitlab.haskell.org/ghc/ghc/-/issues/2836Data.Typeable does not use qualified names2019-07-07T19:06:37ZguestData.Typeable does not use qualified namesThe !TyCon in Data.Typeable does not provide the qualified type name.
This can be very annoying if you try to use a !TypeRep as a stored representation of a type (within a run it's OK with the equality on !TypeRep).
I suggest that the !...The !TyCon in Data.Typeable does not provide the qualified type name.
This can be very annoying if you try to use a !TypeRep as a stored representation of a type (within a run it's OK with the equality on !TypeRep).
I suggest that the !TyCon be enhanced to contain a qualified name, but that the current API be maintained, except for adding some new functions to access qualified name.
If prodded I could provide the Data.Typeable implementation and the fix to ghc.7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/2833internal error: throwTo: unrecognised why_blocked value2019-07-07T19:06:38Zlilacinternal error: throwTo: unrecognised why_blocked valueThe attached file, built with reactive 0.9.6 with the change listed below (fix for reactive bug!#14), exhibits some strange behaviour. When built with -threaded and run without +RTS -N, everything is fine. When run with +RTS -N2, it slow...The attached file, built with reactive 0.9.6 with the change listed below (fix for reactive bug!#14), exhibits some strange behaviour. When built with -threaded and run without +RTS -N, everything is fine. When run with +RTS -N2, it slows down dramatically (using \<10% CPU on each of my cores) and eventually crashes with:
```
Main: internal error: throwTo: unrecognised why_blocked value
(GHC version 6.10.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The change to reactive (from http://hpaste.org/12528\#a2) is to replace snapshotWith in FRP/Reactive/PrimRecursive.hs with:
```
snapshotWith :: forall a b c t. Ord t =>
(a -> b -> c) -> EventG t a -> ReactiveG t b -> EventG t c
snapshotWith f es rs = listEG . zip (eats es) . zipWith f (evals es) $ rats rs (eats es)
evals :: EventG t a -> [a]
evals (Event (Future (Max MaxBound, _))) = []
evals (Event (Future (_, ~(v `Stepper` es)))) = v:evals es
eats :: EventG t a -> [t]
eats (Event (Future (Max MaxBound, ~(_ `Stepper` es)))) = []
eats (Event (Future (Max (NoBound t), ~(_ `Stepper` es)))) = t:eats es
eats (Event (Future (Max MinBound, ~(_ `Stepper` es)))) = eats es
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/2831Floated error expressions get poor strictness, leaving bad arity2019-07-07T19:06:39ZSimon Peyton JonesFloated error expressions get poor strictness, leaving bad arityGHC is careful to ensure that
```
f = \x. case x of
[] -> error "urk"
(y:ys) -> \z. <blah>
```
gets arity 2. It does this by giving `error` an infinite arity. But if the error call is floated out by fu...GHC is careful to ensure that
```
f = \x. case x of
[] -> error "urk"
(y:ys) -> \z. <blah>
```
gets arity 2. It does this by giving `error` an infinite arity. But if the error call is floated out by full laziness thus
```
lvl = error "urk"
f = \x. case x of
[] -> lvl
(y:ys) -> \z. <blah>
```
it's a bit less obvious. But it's ok: the strictness analyser disovers that `lvl` diverges.
Alas, if `f` is marked INLINE, there's a danger that this does not happen properly, perhaps because the inlining happens after strictness analysis. Or because the error message involves the parameter:
```
{-# INLINE f #-}
f = \x. case x of
[] -> error ("urk" ++ x)
(y:ys) -> \z. <blah>
```
I think I've seen this in connection with array indexing (where the error case is the index out of bounds error). I'm recording this ticket so that I don't forget about this problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Floated error expressions get poor strictness, leaving bad arity","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC is careful to ensure that\r\n{{{\r\n f = \\x. case x of \r\n [] -> error \"urk\"\r\n (y:ys) -> \\z. <blah>\r\n}}}\r\ngets arity 2. It does this by giving `error` an infinite arity. But if the error call is floated out by full laziness thus\r\n{{{\r\n lvl = error \"urk\"\r\n f = \\x. case x of \r\n [] -> lvl\r\n (y:ys) -> \\z. <blah>\r\n}}}\r\nit's a bit less obvious. But it's ok: the strictness analyser disovers that `lvl` diverges.\r\n\r\nAlas, if `f` is marked INLINE, there's a danger that this does not happen properly, perhaps because the inlining happens after strictness analysis. Or because the error message involves the parameter:\r\n{{{\r\n {-# INLINE f #-}\r\n f = \\x. case x of\r\n [] -> error (\"urk\" ++ x)\r\n (y:ys) -> \\z. <blah>\r\n}}}\r\nI think I've seen this in connection with array indexing (where the error case is the index out of bounds error). I'm recording this ticket so that I don't forget about this problem.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2829GHC_SEARCH_PATH broken2019-07-07T19:06:39Zdroundy@darcs.netGHC_SEARCH_PATH brokenThis bug is present in at least ghc 6.8.2 and ghc 6.10.1. According to the documentation:
http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/packages.html\#ghc-package-path
One should be able to specify an environment variable lik...This bug is present in at least ghc 6.8.2 and ghc 6.10.1. According to the documentation:
http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/packages.html\#ghc-package-path
One should be able to specify an environment variable like GHC_PACKAGE_PATH=$HOME/foo: in order to add the file foo to the search path. Instead, the search path is completely replaced--which seems unlikely to be the desired behavior, besides being contrary to the documentation.
This feature works fine, however, in ghc 6.6.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC_SEARCH_PATH broken","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This bug is present in at least ghc 6.8.2 and ghc 6.10.1. According to the documentation:\r\n\r\nhttp://www.haskell.org/ghc/docs/6.10.1/html/users_guide/packages.html#ghc-package-path\r\n\r\nOne should be able to specify an environment variable like GHC_PACKAGE_PATH=$HOME/foo: in order to add the file foo to the search path. Instead, the search path is completely replaced--which seems unlikely to be the desired behavior, besides being contrary to the documentation.\r\n\r\nThis feature works fine, however, in ghc 6.6.1.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/2823Another arity expansion bug2020-02-26T21:25:39ZSimon Peyton JonesAnother arity expansion bugRoman reports: I've finally tracked down one big optimisation problem (at least, I
think it is big). Here is a small example:
```
foo :: Eq a => a -> a
{-# NOINLINE foo #-}
foo x = x
bar :: Eq a => a -> a
{-# INLINE [1] bar #-}
bar x =...Roman reports: I've finally tracked down one big optimisation problem (at least, I
think it is big). Here is a small example:
```
foo :: Eq a => a -> a
{-# NOINLINE foo #-}
foo x = x
bar :: Eq a => a -> a
{-# INLINE [1] bar #-}
bar x = let p = foo (x,x)
q = foo (p,p) in fst (fst q)
```
For some reason, bar's arity is 1 which is wrong. If we replace `(fst (fst q))` by `(fst p)`, it gets the correct arity of 2.
The problem is that because of the arity, `(bar $dEq)` is then floated
out as far as possible which breaks fusion if we have RULES for bar.
In case you are interested, this affects `splitSD` in `dph-prim-par/Data/
Array/Parallel/Unlifted/Distributed/Arrays.hs`. I haven't noticed this
previously because we didn't use segmented arrays as much.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Another arity expansion bug","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Roman reports: I've finally tracked down one big optimisation problem (at least, I\r\nthink it is big). Here is a small example:\r\n{{{\r\nfoo :: Eq a => a -> a\r\n{-# NOINLINE foo #-}\r\nfoo x = x\r\n\r\nbar :: Eq a => a -> a\r\n{-# INLINE [1] bar #-}\r\nbar x = let p = foo (x,x)\r\n q = foo (p,p) in fst (fst q)\r\n}}}\r\nFor some reason, bar's arity is 1 which is wrong. If we replace `(fst (fst q))` by `(fst p)`, it gets the correct arity of 2.\r\n\r\nThe problem is that because of the arity, `(bar $dEq)` is then floated\r\nout as far as possible which breaks fusion if we have RULES for bar.\r\nIn case you are interested, this affects `splitSD` in `dph-prim-par/Data/\r\nArray/Parallel/Unlifted/Distributed/Arrays.hs`. I haven't noticed this\r\npreviously because we didn't use segmented arrays as much.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/2805Test ffi009(ghci) fails on PPC Mac OS X2019-07-07T19:06:45ZthorkilnaurTest ffi009(ghci) fails on PPC Mac OS XThe test ffi009(ghci) has failed for a while on PPC Msc OS X (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected):
```
=====> ffi009(ghci)
cd ./ffi/should_run && '/V...The test ffi009(ghci) has failed for a while on PPC Msc OS X (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected):
```
=====> ffi009(ghci)
cd ./ffi/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 98633 Illegal instruction '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 132 )
Stdout:
Testing 5 Int arguments...
True
True
True
True
True
True
True
True
True
True
Testing 11 Double arguments...
Stderr:
*** unexpected failure for ffi009(ghci)
```
An extract from the so-called crash report indicates a jump into the wild:
```
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000002, 0x00000000027ffd04
Crashed Thread: 2
...
Thread 2 Crashed:
0 ??? 0x027ffd04 0 + 41942276
1 ghc 0x012da320 setThreadLocalVar + 16
2 ghc 0x012fa87c ffi_call_DARWIN + 204 (darwin.S:131)
3 ghc 0x012fa3a0 ffi_call + 208 (ffi_darwin.c:457)
4 ghc 0x012cacb8 interpretBCO + 4984
5 ghc 0x012d46d0 schedule + 1024
6 ghc 0x012d4d84 workerStart + 84
7 libSystem.B.dylib 0x9292f658 _pthread_start + 316
```
When the test is run with a ghc built with `GhcDebugged=YES` (see http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and `mk/config.mk`), an assertion failure is reported instead:
```
=====> ffi009(ghci)
cd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 43988 Abort trap '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 134 )
Stdout:
Stderr:
ffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380
(GHC version 6.11.20081121 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** unexpected failure for ffi009(ghci)
```
The assertion failure is reported from this context in `Linker.c`:
```
if(reloc->r_pcrel)
{
#ifdef powerpc_HOST_ARCH
// In the .o file, this should be a relative jump to NULL
// and we'll change it to a relative jump to the symbol
ASSERT(word + reloc->r_address == 0);
jumpIsland = (unsigned long)
&makeSymbolExtra(oc,
reloc->r_symbolnum,
(unsigned long) symbolAddress)
-> jumpIsland;
if(jumpIsland != 0)
{
offsetToJumpIsland = word + jumpIsland
- (((long)image) + sect->offset - sect->addr);
}
#endif
word += (unsigned long) symbolAddress
- (((long)image) + sect->offset - sect->addr);
}
```
The relocations leading to the assertion failure are required by branch instructions generated by `gcc` for `ffi009_stub.c` that contains expressions of the form `symbol+constant` (where `symbol` is an external symbol) whose distance to the instruction needs to be packed into a 24-bit field. An example is
```
bl saveFP+56 ; save f28-f31
```
and there are actually 4 cases like this in the code generated by `gcc` for `ffi009_stub.c`.
This problem does not appear particularly easy to solve: The mechanism used when such a branch needs to address code that cannot be addressed using a 24-bit relative address is to create so-called jump islands, which are small, close-by pieces of code that (hopefully, but see #1845) \*can\* be reached using 24-bit relative addressing. The branch is changed to address the jump island which, in turn, constructs the actual 32-bit address and branches to it. Currently, however, this mechanism, for the PPC Mac OS X architecture, is limited to a single jump island per external symbol and is not capable of handling the addressing of external symbols with constants added to them. Handling the adding of a constant is doable, I believe, but the problem is that the same external symbol may appear multiple times with different constants added. For example, in addition to the above case, the code for `ffi009_stub.c` also includes
```
bl saveFP+28 ; save f21-f31
```
which would require creating two jump islands for the single symbol `saveFP`.
Possible solutions:
1. Make a special case out of the specific symbols concerned here. This would involve creating a limited list of different jump islands for these symbols, to be used when different constants were added.
1. Generalize, somehow, the present jump island mechanism to allow more flexibility. It is undoubtably possible to do this, but it does not seem to be particularly easy to do.
1. The `-mlongjump` option actually causes `gcc` to replace the critical relative brach instructions by inline code, at the expense of generating longer and potentially slower code for all calls and possibly other branches as well. And if we try this, we get:
```
ffi009: internal error:
unknown relocation 13
(GHC version 6.11.20081121 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
(relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended to handle this type also.
Any advice on how to proceed in this matter, additional ideas and views, would be most welcome.
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test ffi009(ghci) fails on PPC Mac OS X","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The test ffi009(ghci) has failed for a while on PPC Msc OS X (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected):\r\n{{{\r\n=====> ffi009(ghci)\r\ncd ./ffi/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr\r\n/bin/sh: line 1: 98633 Illegal instruction '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr\r\nWrong exit code (expected 0 , actual 132 )\r\nStdout:\r\nTesting 5 Int arguments...\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTrue\r\nTesting 11 Double arguments...\r\n\r\nStderr:\r\n\r\n*** unexpected failure for ffi009(ghci)\r\n}}}\r\nAn extract from the so-called crash report indicates a jump into the wild:\r\n{{{\r\nException Type: EXC_BAD_INSTRUCTION (SIGILL)\r\nException Codes: 0x0000000000000002, 0x00000000027ffd04\r\nCrashed Thread: 2\r\n...\r\nThread 2 Crashed:\r\n0 ??? 0x027ffd04 0 + 41942276\r\n1 ghc 0x012da320 setThreadLocalVar + 16\r\n2 ghc 0x012fa87c ffi_call_DARWIN + 204 (darwin.S:131)\r\n3 ghc 0x012fa3a0 ffi_call + 208 (ffi_darwin.c:457)\r\n4 ghc 0x012cacb8 interpretBCO + 4984\r\n5 ghc 0x012d46d0 schedule + 1024\r\n6 ghc 0x012d4d84 workerStart + 84\r\n7 libSystem.B.dylib 0x9292f658 _pthread_start + 316\r\n}}}\r\nWhen the test is run with a ghc built with {{{GhcDebugged=YES}}} (see http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and {{{mk/config.mk}}}), an assertion failure is reported instead:\r\n{{{\r\n=====> ffi009(ghci)\r\ncd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr\r\n/bin/sh: line 1: 43988 Abort trap '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr\r\nWrong exit code (expected 0 , actual 134 )\r\nStdout:\r\n\r\nStderr:\r\nffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380\r\n\r\n (GHC version 6.11.20081121 for powerpc_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*** unexpected failure for ffi009(ghci)\r\n}}}\r\nThe assertion failure is reported from this context in {{{Linker.c}}}:\r\n{{{\r\n if(reloc->r_pcrel)\r\n {\r\n#ifdef powerpc_HOST_ARCH\r\n // In the .o file, this should be a relative jump to NULL\r\n // and we'll change it to a relative jump to the symbol\r\n ASSERT(word + reloc->r_address == 0);\r\n jumpIsland = (unsigned long)\r\n &makeSymbolExtra(oc,\r\n reloc->r_symbolnum,\r\n (unsigned long) symbolAddress)\r\n -> jumpIsland;\r\n if(jumpIsland != 0)\r\n {\r\n offsetToJumpIsland = word + jumpIsland\r\n - (((long)image) + sect->offset - sect->addr);\r\n }\r\n#endif\r\n word += (unsigned long) symbolAddress\r\n - (((long)image) + sect->offset - sect->addr);\r\n }\r\n}}}\r\nThe relocations leading to the assertion failure are required by branch instructions generated by {{{gcc}}} for {{{ffi009_stub.c}}} that contains expressions of the form {{{symbol+constant}}} (where {{{symbol}}} is an external symbol) whose distance to the instruction needs to be packed into a 24-bit field. An example is\r\n{{{\r\n bl saveFP+56 ; save f28-f31\r\n}}}\r\nand there are actually 4 cases like this in the code generated by {{{gcc}}} for {{{ffi009_stub.c}}}.\r\n\r\nThis problem does not appear particularly easy to solve: The mechanism used when such a branch needs to address code that cannot be addressed using a 24-bit relative address is to create so-called jump islands, which are small, close-by pieces of code that (hopefully, but see #1845) *can* be reached using 24-bit relative addressing. The branch is changed to address the jump island which, in turn, constructs the actual 32-bit address and branches to it. Currently, however, this mechanism, for the PPC Mac OS X architecture, is limited to a single jump island per external symbol and is not capable of handling the addressing of external symbols with constants added to them. Handling the adding of a constant is doable, I believe, but the problem is that the same external symbol may appear multiple times with different constants added. For example, in addition to the above case, the code for {{{ffi009_stub.c}}} also includes\r\n{{{\r\n bl saveFP+28 ; save f21-f31\r\n}}}\r\nwhich would require creating two jump islands for the single symbol {{{saveFP}}}.\r\n\r\nPossible solutions:\r\n\r\n 1. Make a special case out of the specific symbols concerned here. This would involve creating a limited list of different jump islands for these symbols, to be used when different constants were added.\r\n 1. Generalize, somehow, the present jump island mechanism to allow more flexibility. It is undoubtably possible to do this, but it does not seem to be particularly easy to do.\r\n 1. The {{{-mlongjump}}} option actually causes {{{gcc}}} to replace the critical relative brach instructions by inline code, at the expense of generating longer and potentially slower code for all calls and possibly other branches as well. And if we try this, we get:\r\n{{{\r\nffi009: internal error: \r\nunknown relocation 13\r\n (GHC version 6.11.20081121 for powerpc_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n (relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended to handle this type also.\r\n\r\nAny advice on how to proceed in this matter, additional ideas and views, would be most welcome.\r\n\r\nBest regards\r\nThorkil","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/2791Allow two versions of GHC to be installed simultaneously with the OS X installer2019-07-07T19:06:49ZIan Lynagh <igloo@earth.li>Allow two versions of GHC to be installed simultaneously with the OS X installerCurrently, for some people at least, installing a 6.10 series OS X installer will remove the 6.8 series GHC. We'd like it to leave the old one there (although the symlinks for commands like `ghc` will no longer point to it).
More detail...Currently, for some people at least, installing a 6.10 series OS X installer will remove the 6.8 series GHC. We'd like it to leave the old one there (although the symlinks for commands like `ghc` will no longer point to it).
More details are in this thread:
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/015904.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow two versions of GHC to be installed simultaneously with the OS X installer","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, for some people at least, installing a 6.10 series OS X installer will remove the 6.8 series GHC. We'd like it to leave the old one there (although the symlinks for commands like `ghc` will no longer point to it).\r\n\r\nMore details are in this thread:\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/015904.html\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2762Excessive heap usage2019-07-07T19:06:59ZIan Lynagh <igloo@earth.li>Excessive heap usageWith `Main.hs`:
```
module Main (main) where
import InputOutput
main :: IO ()
main = do
let content1 = concat (replicate 1000000 "1x") ++ "0"
let i1 = fst $ input content1
view i1
let content2 ...With `Main.hs`:
```
module Main (main) where
import InputOutput
main :: IO ()
main = do
let content1 = concat (replicate 1000000 "1x") ++ "0"
let i1 = fst $ input content1
view i1
let content2 = concat (replicate 1000001 "1y") ++ "0"
let i2 = fst $ input content2
view i2
view :: [Char] -> IO ()
view [] = return ()
view (i : is) = i `seq` view is
```
and `InputOutput.hs`:
```
module InputOutput (input) where
class InputOutput a where
input :: String -> (a, String)
instance InputOutput Char where
input (x : bs) = (x, bs)
instance InputOutput a => InputOutput [a] where
input ('0':bs) = ([], bs)
input ('1':bs) = case input bs of
(x, bs') ->
case input bs' of
~(xs, bs'') -> (x : xs, bs'')
```
according to
```
ghc -O -prof -auto-all --make Main.hs -fforce-recomp
./Main +RTS -h
```
heap usage goes up to about 20M with the HEAD, but only about 200 bytes with 6.8.2.
This is with 6.11.20081108, but I started investigating with the HEAD when I saw similar problems with more-or-less 6.10.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Excessive heap usage","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With `Main.hs`:\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport InputOutput\r\n\r\nmain :: IO ()\r\nmain = do\r\n let content1 = concat (replicate 1000000 \"1x\") ++ \"0\"\r\n let i1 = fst $ input content1\r\n view i1\r\n\r\n let content2 = concat (replicate 1000001 \"1y\") ++ \"0\"\r\n let i2 = fst $ input content2\r\n view i2\r\n\r\nview :: [Char] -> IO ()\r\nview [] = return ()\r\nview (i : is) = i `seq` view is\r\n}}}\r\nand `InputOutput.hs`:\r\n{{{\r\nmodule InputOutput (input) where\r\n\r\nclass InputOutput a where\r\n input :: String -> (a, String)\r\n\r\ninstance InputOutput Char where\r\n input (x : bs) = (x, bs)\r\n\r\ninstance InputOutput a => InputOutput [a] where\r\n input ('0':bs) = ([], bs)\r\n input ('1':bs) = case input bs of\r\n (x, bs') ->\r\n case input bs' of\r\n ~(xs, bs'') -> (x : xs, bs'')\r\n}}}\r\naccording to\r\n{{{\r\nghc -O -prof -auto-all --make Main.hs -fforce-recomp\r\n./Main +RTS -h\r\n}}}\r\nheap usage goes up to about 20M with the HEAD, but only about 200 bytes with 6.8.2. \r\n\r\nThis is with 6.11.20081108, but I started investigating with the HEAD when I saw similar problems with more-or-less 6.10.1.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2731Avoid unnecessary evaluation when unpacking constructors2022-03-07T11:52:47ZSimon Peyton JonesAvoid unnecessary evaluation when unpacking constructorsConsider
```
data T a = MkT !a
foo :: T (a,b) -> a
foo (MkT (x,y)) = x
```
GHC will extract the first component of the `MkT`, *evaluate it*, and then extract the first component of the pair. The evaluation step isn't needed, since the...Consider
```
data T a = MkT !a
foo :: T (a,b) -> a
foo (MkT (x,y)) = x
```
GHC will extract the first component of the `MkT`, *evaluate it*, and then extract the first component of the pair. The evaluation step isn't needed, since the component is known to be already-evaluated. `UNPACK` directives won't work here, because the component is polymorphic.
In the email thread, Tyson posted an example where this extra eval made a significant difference to his inner loop:
[http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015796.html](http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015796.html)
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Avoid unnecessary evaluation when unpacking constructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nConsider \r\n{{{\r\ndata T a = MkT !a\r\n\r\nfoo :: T (a,b) -> a\r\nfoo (MkT (x,y)) = x\r\n}}}\r\nGHC will extract the first component of the `MkT`, ''evaluate it'', and then extract the first component of the pair. The evaluation step isn't needed, since the component is known to be already-evaluated. `UNPACK` directives won't work here, because the component is polymorphic.\r\n\r\nIn the email thread, Tyson posted an example where this extra eval made a significant difference to his inner loop:\r\n[http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015796.html]\r\n\r\nSimon\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/2721Newtype deriving doesn't work with type families2022-02-09T14:08:17Zrl@cse.unsw.edu.auNewtype deriving doesn't work with type familiesThis assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example:
```
class C a where
type T a
foo :: a -> T a
instance C Int where
type T Int = Int
foo = id
newtype N = N Int deriving(C)
```
This happily produces an `insta...This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example:
```
class C a where
type T a
foo :: a -> T a
instance C Int where
type T Int = Int
foo = id
newtype N = N Int deriving(C)
```
This happily produces an `instance C N` but no `type instance T N`. It should either (preferably) generate
```
type instance T N = Int
```
or fail. The example also compiles if `T` is a data family (the `Int` instance needs to be change accordingly). It should probably fail in this case.
BTW, this also compiles fine, with rather dramatic consequences:
```
type family T a
class C a where
foo :: a -> T a
type instance T Int = Int
instance C Int where
foo = id
type instance T N = Double
newtype N = N Int deriving(C)
```
I guess this last example is the same bug as #1496. I wonder if the deriving clause could generate something like:
```
instance T Int ~ T N => C Int
```8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/2715Equality constraint in superclass not supported2019-07-07T19:07:12ZrodpriceEquality constraint in superclass not supportedThe code in "bug.hs" causes a GHC panic; the nearly identical code in "unbug.hs" does not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...The code in "bug.hs" causes a GHC panic; the nearly identical code in "unbug.hs" does not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The code in \"bug.hs\" causes a GHC panic; the nearly identical code in \"unbug.hs\" does not.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2710-main-is flag in {-# OPTIONS #-} pragma not fully supported2019-07-07T19:07:14ZStephan202-main-is flag in {-# OPTIONS #-} pragma not fully supportedThe `-main-is` flag is dynamic an may therefore be placed inside the `{-# OPTIONS #-}` pragma. Version 6.8.3 of *runghc* respects this flag (that is, *runghc* works as expected), but this cannot be said of *ghc*.
### Example file *T.hs*...The `-main-is` flag is dynamic an may therefore be placed inside the `{-# OPTIONS #-}` pragma. Version 6.8.3 of *runghc* respects this flag (that is, *runghc* works as expected), but this cannot be said of *ghc*.
### Example file *T.hs*
```
{-# OPTIONS -main-is T.main #-}
module T where
main :: IO ()
main = putStrLn "Hello world"
```
### Example execution
```
$ ghc --make -o t T.hs
[1 of 1] Compiling T ( T.hs, T.o )
Warning: output was redirected with -o, but no output will be generated
because there is no Main module.
```
### Additional notes
This bug is related to ticket #1312, but the difference is that ticket #1312 only addressed *runghc*, not *ghc*.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-main-is flag in {-# OPTIONS #-} pragma not fully supported","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":["-main-is","ghc"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `-main-is` flag is dynamic an may therefore be placed inside the `{-# OPTIONS #-}` pragma. Version 6.8.3 of ''runghc'' respects this flag (that is, ''runghc'' works as expected), but this cannot be said of ''ghc''.\r\n\r\n=== Example file ''T.hs'' ===\r\n\r\n{{{\r\n{-# OPTIONS -main-is T.main #-}\r\n\r\nmodule T where\r\n\r\nmain :: IO ()\r\nmain = putStrLn \"Hello world\"\r\n}}}\r\n\r\n=== Example execution ===\r\n\r\n{{{\r\n$ ghc --make -o t T.hs\r\n[1 of 1] Compiling T ( T.hs, T.o )\r\nWarning: output was redirected with -o, but no output will be generated\r\nbecause there is no Main module.\r\n}}}\r\n\r\n=== Additional notes ===\r\n\r\nThis bug is related to ticket #1312, but the difference is that ticket #1312 only addressed ''runghc'', not ''ghc''.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/2695bogus "syntactically distinct contexts" error2019-07-07T19:07:19Zconalbogus "syntactically distinct contexts" error```
{-# LANGUAGE TypeOperators, FlexibleContexts
, MultiParamTypeClasses, FunctionalDependencies
, TypeFamilies
-- , ScopedTypeVariables
#-}
-- The ScopedTypeVariables is there just as a bug work-around. Without:
--
-- Mut...```
{-# LANGUAGE TypeOperators, FlexibleContexts
, MultiParamTypeClasses, FunctionalDependencies
, TypeFamilies
-- , ScopedTypeVariables
#-}
-- The ScopedTypeVariables is there just as a bug work-around. Without:
--
-- Mutually dependent functions have syntactically distinct contexts
-- When matching the contexts of the signatures for
-- dZero :: forall b a s.
-- (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) =>
-- a :> b
-- pureD :: forall b a s.
-- (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) =>
-- b -> a :> b
-- The signature contexts in a mutually recursive group should all be identical
-- When generalising the type(s) for dZero, pureD
--
-- This bug was introduced between ghc 6.9.20080622 and 6.10.0.20081007.
{-# OPTIONS_GHC -fno-warn-missing-methods #-}
import Control.Applicative
class AdditiveGroup v where
zeroV :: v
(^+^) :: v -> v -> v
negateV :: v -> v
class AdditiveGroup v => VectorSpace v s | v -> s where
(*^) :: s -> v -> v
-- | Mapping from all elements of @a@ to the results of some function
class HasTrie a where
data (:->:) a :: * -> *
instance HasTrie a => Functor ((:->:) a)
instance HasTrie a => Applicative ((:->:) a)
class VectorSpace v s => HasBasis v s where
type Basis v :: *
-- | Linear map, represented a as a memo function from basis to values.
type u :-* v = Basis u :->: v
data a :> b = D { powVal :: b, derivative :: a :-* (a :> b) }
dZero :: (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => a:>b
dZero = pureD zeroV
pureD :: (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => b -> a:>b
pureD b = b `D` pure dZero
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | conal |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bogus \"syntactically distinct contexts\" error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["conal"],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TypeOperators, FlexibleContexts\r\n , MultiParamTypeClasses, FunctionalDependencies\r\n , TypeFamilies\r\n -- , ScopedTypeVariables\r\n #-}\r\n\r\n-- The ScopedTypeVariables is there just as a bug work-around. Without:\r\n-- \r\n-- Mutually dependent functions have syntactically distinct contexts\r\n-- When matching the contexts of the signatures for\r\n-- dZero :: forall b a s.\r\n-- (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) =>\r\n-- a :> b\r\n-- pureD :: forall b a s.\r\n-- (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) =>\r\n-- b -> a :> b\r\n-- The signature contexts in a mutually recursive group should all be identical\r\n-- When generalising the type(s) for dZero, pureD\r\n-- \r\n-- This bug was introduced between ghc 6.9.20080622 and 6.10.0.20081007.\r\n\r\n{-# OPTIONS_GHC -fno-warn-missing-methods #-}\r\n\r\n\r\nimport Control.Applicative\r\n\r\nclass AdditiveGroup v where\r\n zeroV :: v\r\n (^+^) :: v -> v -> v\r\n negateV :: v -> v\r\n\r\nclass AdditiveGroup v => VectorSpace v s | v -> s where\r\n (*^) :: s -> v -> v\r\n\r\n\r\n-- | Mapping from all elements of @a@ to the results of some function\r\nclass HasTrie a where\r\n data (:->:) a :: * -> *\r\n\r\ninstance HasTrie a => Functor ((:->:) a)\r\n\r\ninstance HasTrie a => Applicative ((:->:) a)\r\n\r\nclass VectorSpace v s => HasBasis v s where\r\n type Basis v :: *\r\n\r\n-- | Linear map, represented a as a memo function from basis to values.\r\ntype u :-* v = Basis u :->: v\r\n\r\ndata a :> b = D { powVal :: b, derivative :: a :-* (a :> b) }\r\n\r\ndZero :: (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => a:>b\r\ndZero = pureD zeroV\r\n\r\npureD :: (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => b -> a:>b\r\npureD b = b `D` pure dZero\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2664type family + data family + typeclass + type error causes GHC to diverge2019-07-07T19:07:27Zryanitype family + data family + typeclass + type error causes GHC to diverge```
ryani:~ ryani$ ghc-6.11.20081005 -c overflow.hs
<about 15 seconds pass>
stack overflow: use +RTS -K<size> to increase it
ryani:~ ryani$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---...```
ryani:~ ryani$ ghc-6.11.20081005 -c overflow.hs
<about 15 seconds pass>
stack overflow: use +RTS -K<size> to increase it
ryani:~ ryani$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"type family + data family + typeclass + type error causes GHC to diverge","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nryani:~ ryani$ ghc-6.11.20081005 -c overflow.hs \r\n<about 15 seconds pass>\r\nstack overflow: use +RTS -K<size> to increase it\r\nryani:~ ryani$ \r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2658Extreme memory usage (probably type functions)2019-07-07T19:07:28ZguestExtreme memory usage (probably type functions)This is with the ghc 6.10.1 rc:
http://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs-testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a
Then a perf build.
Then, wget http://hackage.haskell.org/pac...This is with the ghc 6.10.1 rc:
http://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs-testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a
Then a perf build.
Then, wget http://hackage.haskell.org/packages/archive/sessions/2008.7.18/sessions-2008.7.18.tar.gz, unpack and cd sessions-2008.7.18
ghci-6.8.3 Tests/Tests.hs. This takes 40 seconds to get to the prompt and uses about 700MB memory.
ghci-6.10.0.20081004 Tests/Tests.hs. This has not finished type checking yet (well over 5 mins now - it exhaused my 4GB RAM and is now eating its way through 16GB of swap). top reports it's currently using about 5GB memory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Extreme memory usage","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is with the ghc 6.10.1 rc:\r\n\r\nhttp://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs-testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a\r\n\r\nThen a perf build.\r\n\r\nThen, wget http://hackage.haskell.org/packages/archive/sessions/2008.7.18/sessions-2008.7.18.tar.gz, unpack and cd sessions-2008.7.18\r\n\r\nghci-6.8.3 Tests/Tests.hs. This takes 40 seconds to get to the prompt and uses about 700MB memory.\r\n\r\nghci-6.10.0.20081004 Tests/Tests.hs. This has not finished type checking yet (well over 5 mins now - it exhaused my 4GB RAM and is now eating its way through 16GB of swap). top reports it's currently using about 5GB memory.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2609Compiling with -O2 is 7x slower than -O2019-07-07T19:07:42ZSimon Peyton JonesCompiling with -O2 is 7x slower than -OSerge writes that compiling !DoCon with `-O2 -fvia-C` "does not gain more performance, but leads to 7 times longer compilation". That seems a big slow down, worth looking into.
The offending !DoCon bundle is attached
<details><summary>...Serge writes that compiling !DoCon with `-O2 -fvia-C` "does not gain more performance, but leads to 7 times longer compilation". That seems a big slow down, worth looking into.
The offending !DoCon bundle is attached
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with -O2 is 7x slower than -O","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Serge writes that compiling !DoCon with `-O2 -fvia-C` \"does not gain more performance, but leads to 7 times longer compilation\". That seems a big slow down, worth looking into.\r\n\r\nThe offending !DoCon bundle is attached","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2600Bind type variables in RULES2019-07-07T19:07:44ZSimon Peyton JonesBind type variables in RULESRoman writes: here's an example I came across while working on the recycling paper
and which I subsequently forgot about. Suppose we have:
```
{-# LANGUAGE Rank2Types #-}
module T where
class T t where
to :: [a] -> t a
from :: ...Roman writes: here's an example I came across while working on the recycling paper
and which I subsequently forgot about. Suppose we have:
```
{-# LANGUAGE Rank2Types #-}
module T where
class T t where
to :: [a] -> t a
from :: t a -> [a]
tmap :: (a -> a) -> t a -> t a
{-# RULES
"myrule" forall f x.
from (tmap f (to x)) = map f (from (to x))
#-}
```
Alas, this fails with:
```
Ambiguous type variable `t' in the constraint:
`T t' arising from a use of `to' at T.hs:12:40-43
Probable fix: add a type signature that fixes these type variable(s)
```
Of course, I'd like the t on the rhs to be the same as on the lhs but
I don't see how to tell this to GHC. Is it actually possible? The only
solution I've found was to add a dummy argument to 'to':
```
to' :: t a -> [a] -> t a
to = to' undefined
{-# RULES
"myrule" forall f t x.
from (tmap f (to' t x)) = map f (from (to' t x))
#-}
```
That's ugly, of course. Am I missing something or is this just
impossible to do with the current system?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Bind type variables in RULES","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Roman writes: here's an example I came across while working on the recycling paper\r\nand which I subsequently forgot about. Suppose we have:\r\n{{{\r\n{-# LANGUAGE Rank2Types #-}\r\nmodule T where\r\n\r\nclass T t where\r\n to :: [a] -> t a\r\n from :: t a -> [a]\r\n tmap :: (a -> a) -> t a -> t a\r\n\r\n{-# RULES\r\n\r\n\"myrule\" forall f x.\r\n from (tmap f (to x)) = map f (from (to x))\r\n #-}\r\n}}}\r\nAlas, this fails with:\r\n{{{\r\n Ambiguous type variable `t' in the constraint:\r\n `T t' arising from a use of `to' at T.hs:12:40-43\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n}}}\r\nOf course, I'd like the t on the rhs to be the same as on the lhs but\r\nI don't see how to tell this to GHC. Is it actually possible? The only\r\nsolution I've found was to add a dummy argument to 'to':\r\n{{{\r\nto' :: t a -> [a] -> t a\r\n\r\nto = to' undefined\r\n\r\n{-# RULES\r\n\r\n\"myrule\" forall f t x.\r\n from (tmap f (to' t x)) = map f (from (to' t x))\r\n #-}\r\n}}}\r\nThat's ugly, of course. Am I missing something or is this just\r\nimpossible to do with the current system?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2599Improve error message for type rigidity2019-07-07T19:07:45ZSimon Peyton JonesImprove error message for type rigidityWhen saying that a GADT match is given a non-rigid type, we should be more explicit about where a type signature would help. For example, given the program:
```
data E x = E x
data Foo a where
Foo :: Gadt a -> Foo a
data Gadt a wher...When saying that a GADT match is given a non-rigid type, we should be more explicit about where a type signature would help. For example, given the program:
```
data E x = E x
data Foo a where
Foo :: Gadt a -> Foo a
data Gadt a where
GadtValue :: a -> Gadt (E a)
g = case undefined of
Foo GadtValue -> ()
```
I get the error message:
```
Test.hs:13:12:
GADT pattern match with non-rigid result type `t'
Solution: add a type signature
In a case alternative: Foo GadtValue -> ()
In the expression: case undefined of { Foo GadtValue -> () }
In the definition of `g':
g = case undefined of { Foo GadtValue -> () }
```
But where should the type signature be? A better hint would be:
```
Solution: add a type signature, probably at _TYPE_
(case undefined of { Foo GadtValue -> () }) :: _TYPE_
```
Similarly, we know when it's the scrutinee that needs a signature. And in a do-binding the "scrutinee" is really the right-hand side. We can get all this information from the matching context.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Improve error message for type rigidity","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"When saying that a GADT match is given a non-rigid type, we should be more explicit about where a type signature would help. For example, given the program:\r\n{{{\r\ndata E x = E x\r\n\r\ndata Foo a where\r\n Foo :: Gadt a -> Foo a\r\n\r\ndata Gadt a where\r\n GadtValue :: a -> Gadt (E a)\r\n\r\ng = case undefined of\r\n Foo GadtValue -> ()\r\n}}}\r\nI get the error message:\r\n{{{\r\nTest.hs:13:12:\r\n GADT pattern match with non-rigid result type `t'\r\n Solution: add a type signature\r\n In a case alternative: Foo GadtValue -> ()\r\n In the expression: case undefined of { Foo GadtValue -> () }\r\n In the definition of `g':\r\n g = case undefined of { Foo GadtValue -> () }\r\n}}}\r\nBut where should the type signature be? A better hint would be:\r\n{{{\r\nSolution: add a type signature, probably at _TYPE_\r\n(case undefined of { Foo GadtValue -> () }) :: _TYPE_\r\n}}}\r\nSimilarly, we know when it's the scrutinee that needs a signature. And in a do-binding the \"scrutinee\" is really the right-hand side. We can get all this information from the matching context.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon Peyton JonesSimon Peyton Jones