GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:26:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12357Increasing maximum constraint tuple size significantly blows up compiler allo...2019-07-07T18:26:56ZBen GamariIncreasing maximum constraint tuple size significantly blows up compiler allocationsIn July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum constraint tuple size was raised from 16 to 62 to address #10451. It turns out that this change is apparently one of the larger compile-time regressions in recent GHC hi...In July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum constraint tuple size was raised from 16 to 62 to address #10451. It turns out that this change is apparently one of the larger compile-time regressions in recent GHC history. For instance, the nofib `real/fulsom/Shapes.hs` module regresses by around 15% in both compiler allocations and compile time.
Judging by ticky and the cost-center profiler the performance regression appears to simply be the result of the loading the new declarations from the interface file, as one might expect. Nevertheless, it's quite silly to pay such a large price for a change that only gets occasionally exercised.8.2.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12355Invalid assembly in foreign prim2019-07-07T18:26:57ZÖmer Sinan AğacanInvalid assembly in foreign prim```
➜ prim_panic ghc Lib.hs
[1 of 1] Compiling Lib ( Lib.hs, Lib.o )
/tmp/ghc14440_0/ghc_2.s: Assembler messages:
/tmp/ghc14440_0/ghc_2.s:65:0: error:
Error: number of operands mismatch for `jmp'
`gcc' failed in phase...```
➜ prim_panic ghc Lib.hs
[1 of 1] Compiling Lib ( Lib.hs, Lib.o )
/tmp/ghc14440_0/ghc_2.s: Assembler messages:
/tmp/ghc14440_0/ghc_2.s:65:0: error:
Error: number of operands mismatch for `jmp'
`gcc' failed in phase `Assembler'. (Exit code: 1)
➜ prim_panic cat Lib.hs
{-# LANGUAGE GHCForeignImportPrim, UnliftedFFITypes, MagicHash #-}
module Lib where
import GHC.Prim
foreign import prim f1 :: Int# -> Int#
```
Tried with: HEAD as of today, 8.0.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Invalid assembly in foreign prim","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n➜ prim_panic ghc Lib.hs\r\n[1 of 1] Compiling Lib ( Lib.hs, Lib.o )\r\n/tmp/ghc14440_0/ghc_2.s: Assembler messages:\r\n\r\n/tmp/ghc14440_0/ghc_2.s:65:0: error:\r\n Error: number of operands mismatch for `jmp'\r\n`gcc' failed in phase `Assembler'. (Exit code: 1)\r\n➜ prim_panic cat Lib.hs\r\n{-# LANGUAGE GHCForeignImportPrim, UnliftedFFITypes, MagicHash #-}\r\n\r\nmodule Lib where\r\n\r\nimport GHC.Prim\r\n\r\nforeign import prim f1 :: Int# -> Int#\r\n}}}\r\n\r\nTried with: HEAD as of today, 8.0.1.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12354Word foldl' isn't optimized as well as Int foldl'2019-07-07T18:26:57ZkjslagWord foldl' isn't optimized as well as Int foldl'```hs
import Data.List
test :: Int -> Int
test n = foldl' (+) 0 [1..n]
main :: IO ()
main = do
print $ test $ 10^8
```
GHC optimizes the above code to the point that the garbage collector doesn't even have to do anything:
```
$ ghc...```hs
import Data.List
test :: Int -> Int
test n = foldl' (+) 0 [1..n]
main :: IO ()
main = do
print $ test $ 10^8
```
GHC optimizes the above code to the point that the garbage collector doesn't even have to do anything:
```
$ ghc -rtsopts -O2 testInt && ./testInt +RTS -s
[1 of 1] Compiling Main ( testInt.hs, testInt.o )
Linking testInt ...
5000000050000000
51,752 bytes allocated in the heap
3,480 bytes copied during GC
44,384 bytes maximum residency (1 sample(s))
17,056 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s
Gen 1 1 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s
INIT time 0.000s ( 0.000s elapsed)
MUT time 0.101s ( 0.101s elapsed)
GC time 0.000s ( 0.000s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 0.103s ( 0.102s elapsed)
%GC time 0.1% (0.1% elapsed)
Alloc rate 511,162 bytes per MUT second
Productivity 99.8% of total user, 100.9% of total elapsed
```
However, if I change the type of `test` to `test :: Word -> Word`, then a lot of garbage is produced and the code runs 40x slower:
```
ghc -rtsopts -O2 testWord && ./testWord +RTS -s
[1 of 1] Compiling Main ( testWord.hs, testWord.o )
Linking testWord ...
5000000050000000
11,200,051,784 bytes allocated in the heap
1,055,520 bytes copied during GC
44,384 bytes maximum residency (2 sample(s))
21,152 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 21700 colls, 0 par 0.077s 0.073s 0.0000s 0.0000s
Gen 1 2 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s
INIT time 0.000s ( 0.000s elapsed)
MUT time 4.551s ( 4.556s elapsed)
GC time 0.077s ( 0.073s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 4.630s ( 4.630s elapsed)
%GC time 1.7% (1.6% elapsed)
Alloc rate 2,460,957,186 bytes per MUT second
Productivity 98.3% of total user, 98.3% of total elapsed
```
I expected the performance to be nearly identical.
I'm using GHC version 8.0.1 on x86_64 Arch Linux.
I asked about this on stackoverflow, and the issue appears to be related to rewrite rules:
[http://stackoverflow.com/a/38113639/6531137](http://stackoverflow.com/a/38113639/6531137)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Word foldl' isn't optimized as well as Int foldl'","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nimport Data.List\r\n\r\ntest :: Int -> Int\r\ntest n = foldl' (+) 0 [1..n]\r\n\r\nmain :: IO ()\r\nmain = do\r\n print $ test $ 10^8\r\n}}}\r\n\r\nGHC optimizes the above code to the point that the garbage collector doesn't even have to do anything:\r\n\r\n{{{\r\n$ ghc -rtsopts -O2 testInt && ./testInt +RTS -s\r\n[1 of 1] Compiling Main ( testInt.hs, testInt.o )\r\nLinking testInt ...\r\n5000000050000000\r\n 51,752 bytes allocated in the heap\r\n 3,480 bytes copied during GC\r\n 44,384 bytes maximum residency (1 sample(s))\r\n 17,056 bytes maximum slop\r\n 1 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s\r\n Gen 1 1 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s\r\n\r\n INIT time 0.000s ( 0.000s elapsed)\r\n MUT time 0.101s ( 0.101s elapsed)\r\n GC time 0.000s ( 0.000s elapsed)\r\n EXIT time 0.000s ( 0.000s elapsed)\r\n Total time 0.103s ( 0.102s elapsed)\r\n\r\n %GC time 0.1% (0.1% elapsed)\r\n\r\n Alloc rate 511,162 bytes per MUT second\r\n\r\n Productivity 99.8% of total user, 100.9% of total elapsed\r\n}}}\r\n\r\nHowever, if I change the type of {{{test}}} to {{{test :: Word -> Word}}}, then a lot of garbage is produced and the code runs 40x slower:\r\n\r\n{{{\r\nghc -rtsopts -O2 testWord && ./testWord +RTS -s\r\n[1 of 1] Compiling Main ( testWord.hs, testWord.o )\r\nLinking testWord ...\r\n5000000050000000\r\n 11,200,051,784 bytes allocated in the heap\r\n 1,055,520 bytes copied during GC\r\n 44,384 bytes maximum residency (2 sample(s))\r\n 21,152 bytes maximum slop\r\n 1 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 21700 colls, 0 par 0.077s 0.073s 0.0000s 0.0000s\r\n Gen 1 2 colls, 0 par 0.000s 0.000s 0.0001s 0.0001s\r\n\r\n INIT time 0.000s ( 0.000s elapsed)\r\n MUT time 4.551s ( 4.556s elapsed)\r\n GC time 0.077s ( 0.073s elapsed)\r\n EXIT time 0.000s ( 0.000s elapsed)\r\n Total time 4.630s ( 4.630s elapsed)\r\n\r\n %GC time 1.7% (1.6% elapsed)\r\n\r\n Alloc rate 2,460,957,186 bytes per MUT second\r\n\r\n Productivity 98.3% of total user, 98.3% of total elapsed\r\n}}}\r\n\r\nI expected the performance to be nearly identical.\r\nI'm using GHC version 8.0.1 on x86_64 Arch Linux.\r\n\r\nI asked about this on stackoverflow, and the issue appears to be related to rewrite rules:\r\n[http://stackoverflow.com/a/38113639/6531137]","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12343base/tests/topHandler03.run failures2019-07-07T18:26:58Zniteriabase/tests/topHandler03.run failuresThis fails on my machine, but appears to work on harbormaster.
This is what I get:
```
=====> topHandler03(normal) 1 of 1 [0, 0, 0]
cd "../../libraries/base/tests/topHandler03.run" && "/data/users/bnitka/ghc-kill-ufmToList-validate/in...This fails on my machine, but appears to work on harbormaster.
This is what I get:
```
=====> topHandler03(normal) 1 of 1 [0, 0, 0]
cd "../../libraries/base/tests/topHandler03.run" && "/data/users/bnitka/ghc-kill-ufmToList-validate/inplace/test spaces/ghc-stage2" -o topHandler03 topHandler03.hs -dcore-lint
-dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups
cd "../../libraries/base/tests/topHandler03.run" && ./topHandler03
Actual stderr output differs from expected:
--- ../../libraries/base/tests/topHandler03.run/topHandler03.stderr.normalised 2016-06-30 10:18:07.313602229 -0700
+++ ../../libraries/base/tests/topHandler03.run/topHandler03.run.stderr.normalised 2016-06-30 10:18:07.314602263 -0700
@@ -1 +1 @@
-Terminated
+/bin/sh: line 1: 2294693 Terminated ./topHandler03
*** unexpected failure for topHandler03(normal)
```
It used to work, I believe it worked few days ago.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thomie |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"base/tests/topHandler03.run failures","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["thomie"],"type":"Bug","description":"This fails on my machine, but appears to work on harbormaster.\r\n\r\nThis is what I get:\r\n{{{\r\n=====> topHandler03(normal) 1 of 1 [0, 0, 0]\r\ncd \"../../libraries/base/tests/topHandler03.run\" && \"/data/users/bnitka/ghc-kill-ufmToList-validate/inplace/test spaces/ghc-stage2\" -o topHandler03 topHandler03.hs -dcore-lint\r\n -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups\r\ncd \"../../libraries/base/tests/topHandler03.run\" && ./topHandler03\r\nActual stderr output differs from expected:\r\n--- ../../libraries/base/tests/topHandler03.run/topHandler03.stderr.normalised 2016-06-30 10:18:07.313602229 -0700\r\n+++ ../../libraries/base/tests/topHandler03.run/topHandler03.run.stderr.normalised 2016-06-30 10:18:07.314602263 -0700\r\n@@ -1 +1 @@\r\n-Terminated\r\n+/bin/sh: line 1: 2294693 Terminated ./topHandler03\r\n*** unexpected failure for topHandler03(normal)\r\n}}}\r\n\r\nIt used to work, I believe it worked few days ago.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/12271Remove magic from type defaulting2019-07-07T18:26:58ZEric CrockettRemove magic from type defaultingThe Prelude is great, but there are reasons people use drop-in replacements as well. In particular, I'm using \[numeric-prelude\] for its more mathematical numeric type class hierarchy. Unfortunately, I don't get type defaulting with the...The Prelude is great, but there are reasons people use drop-in replacements as well. In particular, I'm using \[numeric-prelude\] for its more mathematical numeric type class hierarchy. Unfortunately, I don't get type defaulting with their numeric type class replacements, which makes some operations a real pain to use.
For example, GHC accepts the following:
```
main :: IO ()
main = print $ 2^2
```
but not
```
{-# LANGUAGE NoImplicitPrelude, RebindableSyntax #-}
import Algebra.Ring as Ring (C)
import Algebra.ToInteger as ToInteger (C)
import NumericPrelude hiding ((^))
(^) :: (Ring.C a, ToInteger.C i) => a -> i -> a
x0 ^ y0 = undefined
main :: IO ()
main = print $ 2^2
```
(there are ambiguous types on both occurrences of `2`.) The [HaskellReport](https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4) seems to suggest that there is no way to use the `default` keyword to get type defaulting in this case.
What I'm asking for is a programmatic way to set defaulting rules for non-standard numeric classes. In terms of implementation, my naive approach would be to remove `Num` from the process altogether: if we ever see a "integer-looking" literal and its type cannot be inferred, always default it to the `IntDefault` type (which could be the same as the current "automatic" default, or the value in the `default` tuple if present). I'm guessing that this approach has some flaws; perhaps someone can point them out?
Barring that, I suppose we need a way to specify a `Num` replacement. In the case of numeric-prelude, it would be `Algebra.Additive.C`. An even more flexible approach would be to allow defaulting for constants with a specific constraint. (That's equivalent to specifying a default type for constants with the constraint `Num a => a` and a possibly different default for `Integral a => a`.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove magic from type defaulting","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The Prelude is great, but there are reasons people use drop-in replacements as well. In particular, I'm using [numeric-prelude] for its more mathematical numeric type class hierarchy. Unfortunately, I don't get type defaulting with their numeric type class replacements, which makes some operations a real pain to use.\r\n\r\nFor example, GHC accepts the following:\r\n{{{\r\nmain :: IO ()\r\nmain = print $ 2^2\r\n}}}\r\n\r\nbut not\r\n{{{\r\n{-# LANGUAGE NoImplicitPrelude, RebindableSyntax #-}\r\n\r\nimport Algebra.Ring as Ring (C)\r\nimport Algebra.ToInteger as ToInteger (C)\r\nimport NumericPrelude hiding ((^))\r\n\r\n(^) :: (Ring.C a, ToInteger.C i) => a -> i -> a\r\nx0 ^ y0 = undefined\r\n\r\nmain :: IO ()\r\nmain = print $ 2^2\r\n}}}\r\n\r\n(there are ambiguous types on both occurrences of `2`.) The [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4 HaskellReport] seems to suggest that there is no way to use the `default` keyword to get type defaulting in this case.\r\n\r\nWhat I'm asking for is a programmatic way to set defaulting rules for non-standard numeric classes. In terms of implementation, my naive approach would be to remove `Num` from the process altogether: if we ever see a \"integer-looking\" literal and its type cannot be inferred, always default it to the `IntDefault` type (which could be the same as the current \"automatic\" default, or the value in the `default` tuple if present). I'm guessing that this approach has some flaws; perhaps someone can point them out?\r\n\r\nBarring that, I suppose we need a way to specify a `Num` replacement. In the case of numeric-prelude, it would be `Algebra.Additive.C`. An even more flexible approach would be to allow defaulting for constants with a specific constraint. (That's equivalent to specifying a default type for constants with the constraint `Num a => a` and a possibly different default for `Integral a => a`.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12262Binary output is not deterministic2019-07-07T18:26:59ZniteriaBinary output is not deterministicThe goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment.
There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that.
Known cause...The goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment.
There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that.
Known causes of binary nondeterminism:
- Unique comparison
- Uniques converted to strings for symbol names
- everything else from #4012
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Binary output is not deterministic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment.\r\nThere's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that.\r\n\r\nKnown causes of binary nondeterminism:\r\n\r\n* Unique comparison\r\n* Uniques converted to strings for symbol names\r\n* everything else from #4012","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12248Simple program that runs 100x slower using Text or ByteString vs. String2019-07-07T18:26:59ZdsfSimple program that runs 100x slower using Text or ByteString vs. StringHere is a repository that just contains a simple function slowText that takes a long list of String / Text / ByteString and appends them using a function based on what happens in the UnitLargeDoc test of the pretty package. A list of Str...Here is a repository that just contains a simple function slowText that takes a long list of String / Text / ByteString and appends them using a function based on what happens in the UnitLargeDoc test of the pretty package. A list of String with 10,000,000 elements can be processed in about 5 seconds on my machine. Lists that long blow the stack if the element type is Text or ByteString. For shorter lists, the element processing time is 100x longer or more.
git repo: https://github.com/ddssff/slowtext
travis output: https://travis-ci.org/ddssff/slowtext/builds
The 7.10 and 8.0.2 tests are running properly and failing because the Text and ByteString tests take longer than String. I will fix the others shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Simple program that runs 100x slower using Text or ByteString vs. String","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Here is a repository that just contains a simple function slowText that takes a long list of String / Text / ByteString and appends them using a function based on what happens in the UnitLargeDoc test of the pretty package. A list of String with 10,000,000 elements can be processed in about 5 seconds on my machine. Lists that long blow the stack if the element type is Text or ByteString. For shorter lists, the element processing time is 100x longer or more.\r\n\r\ngit repo: https://github.com/ddssff/slowtext\r\n\r\ntravis output: https://travis-ci.org/ddssff/slowtext/builds\r\n\r\nThe 7.10 and 8.0.2 tests are running properly and failing because the Text and ByteString tests take longer than String. I will fix the others shortly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12245Deriving Data at higher kinds2020-06-11T13:34:25ZSimon Peyton JonesDeriving Data at higher kindsHere's what [Lennart Spitzner wanted to do](https://mail.haskell.org/pipermail/generics/2016-June/000564.html):
```
> {-# LANGUAGE StandaloneDeriving #-}
> {-# LANGUAGE DeriveDataTypeable #-}
> {-# LANGUAGE FlexibleInstances #-}
>
> im...Here's what [Lennart Spitzner wanted to do](https://mail.haskell.org/pipermail/generics/2016-June/000564.html):
```
> {-# LANGUAGE StandaloneDeriving #-}
> {-# LANGUAGE DeriveDataTypeable #-}
> {-# LANGUAGE FlexibleInstances #-}
>
> import Data.Data ( Data )
>
> data Foo f = Foo (f Bool) (f Int)
>
> deriving instance Data (Foo [])
> deriving instance Data (Foo Maybe)
```
Of course you can't derive `Data` for `Foo` because we don't know what `f` is, so Lennart is making multiple instances, one for each instance of `f`. It's a bit clumsy. What we would really like is
```
deriving instance (forall a. Data => Data (f a)) => Data (Foo f)
```
but we don't have higher order instances yet! So Lennart is manually making two instances.
This should work, but he gets
```
> Main.hs: line 45, column 1:
> Multiple declarations of ‘$cr2C’
> Declared at: Main.hs:44:1
> Main.hs:45:1
> Main.hs: line 45, column 1:
> Multiple declarations of ‘$tr2D’
> Declared at: Main.hs:44:1
> Main.hs:45:1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Deriving Data at higher kinds","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's what [https://mail.haskell.org/pipermail/generics/2016-June/000564.html Lennart Spitzner wanted to do]:\r\n{{{\r\n> {-# LANGUAGE StandaloneDeriving #-}\r\n> {-# LANGUAGE DeriveDataTypeable #-}\r\n> {-# LANGUAGE FlexibleInstances #-}\r\n> \r\n> import Data.Data ( Data )\r\n>\r\n> data Foo f = Foo (f Bool) (f Int)\r\n> \r\n> deriving instance Data (Foo [])\r\n> deriving instance Data (Foo Maybe)\r\n}}}\r\nOf course you can't derive `Data` for `Foo` because we don't know what `f` is, so Lennart is making multiple instances, one for each instance of `f`. It's a bit clumsy. What we would really like is\r\n{{{\r\nderiving instance (forall a. Data => Data (f a)) => Data (Foo f)\r\n}}}\r\nbut we don't have higher order instances yet! So Lennart is manually making two instances. \r\n\r\nThis should work, but he gets\r\n{{{\r\n> Main.hs: line 45, column 1:\r\n> Multiple declarations of ‘$cr2C’\r\n> Declared at: Main.hs:44:1\r\n> Main.hs:45:1\r\n> Main.hs: line 45, column 1:\r\n> Multiple declarations of ‘$tr2D’\r\n> Declared at: Main.hs:44:1\r\n> Main.hs:45:1\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/12243RebindableSyntax and OverloadedLabels2022-05-30T20:10:04ZhtebalakaRebindableSyntax and OverloadedLabelsShould these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that part...Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful.
I didn't see any discussion on this, and it seemed like maybe it's an oversight.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RebindableSyntax and OverloadedLabels","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful.\r\n\r\nI didn't see any discussion on this, and it seemed like maybe it's an oversight.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Adam GundryAdam Gundryhttps://gitlab.haskell.org/ghc/ghc/-/issues/12242panic with complicated type/kind/class expressions2019-07-07T18:27:00ZAshley Yakeleypanic with complicated type/kind/class expressionsI tried to simplify this as much as I could, but I couldn't boil it down further than this:
```hs
-- ghc -O -ddump-hi -ddump-to-file Bug.hs
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE GADTs #-}
module Bug where
...I tried to simplify this as much as I could, but I couldn't boil it down further than this:
```hs
-- ghc -O -ddump-hi -ddump-to-file Bug.hs
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE GADTs #-}
module Bug where
{
import Data.Kind;
data HetEq (a :: ka) (b :: kb) where
{
ReflH :: forall (k :: *) (t :: k). HetEq t t;
};
data Rep :: forall (k :: *). k -> * where
{
SimpleRep :: forall (k :: *) (a :: k). Rep a;
ApplyRep :: forall (k1 :: *) (k2 :: *) (p :: k1 -> k2) (a :: k1). Rep p -> Rep a -> Rep (p a);
};
class TestHetEquality (w :: forall k. k -> *) where
{
testHetEquality :: forall (ka :: *) (a :: ka) (kb :: *) (b :: kb). w a -> w b -> Maybe (HetEq a b);
};
instance TestHetEquality Rep where
{
testHetEquality (ApplyRep tfa ta) (ApplyRep tfb tb) = do
{
ReflH <- testHetEquality tfa tfb;
ReflH <- testHetEquality ta tb;
return ReflH;
};
testHetEquality _ _ = Nothing;
};
bug :: forall (a :: *). Rep (Maybe a) -> Maybe (Rep a);
bug (ApplyRep tf ta) = case testHetEquality tf SimpleRep of
{
Just ReflH -> Just ta;
Nothing -> Nothing;
};
bug _ = Nothing;
}
```
You'll need `-O` and `-ddump-hi` to trigger it.
```
$ stack exec -- ghc -O -ddump-hi -ddump-to-file Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
pprIfaceCo
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"panic with complicated type/kind/class expressions","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to simplify this as much as I could, but I couldn't boil it down further than this:\r\n\r\n{{{#!hs\r\n-- ghc -O -ddump-hi -ddump-to-file Bug.hs\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE GADTs #-}\r\nmodule Bug where\r\n{\r\n import Data.Kind;\r\n\r\n data HetEq (a :: ka) (b :: kb) where\r\n {\r\n ReflH :: forall (k :: *) (t :: k). HetEq t t;\r\n };\r\n\r\n data Rep :: forall (k :: *). k -> * where\r\n {\r\n SimpleRep :: forall (k :: *) (a :: k). Rep a;\r\n ApplyRep :: forall (k1 :: *) (k2 :: *) (p :: k1 -> k2) (a :: k1). Rep p -> Rep a -> Rep (p a);\r\n };\r\n\r\n class TestHetEquality (w :: forall k. k -> *) where\r\n {\r\n testHetEquality :: forall (ka :: *) (a :: ka) (kb :: *) (b :: kb). w a -> w b -> Maybe (HetEq a b);\r\n };\r\n\r\n instance TestHetEquality Rep where\r\n {\r\n testHetEquality (ApplyRep tfa ta) (ApplyRep tfb tb) = do\r\n {\r\n ReflH <- testHetEquality tfa tfb;\r\n ReflH <- testHetEquality ta tb;\r\n return ReflH;\r\n };\r\n testHetEquality _ _ = Nothing;\r\n };\r\n\r\n bug :: forall (a :: *). Rep (Maybe a) -> Maybe (Rep a);\r\n bug (ApplyRep tf ta) = case testHetEquality tf SimpleRep of\r\n {\r\n Just ReflH -> Just ta;\r\n Nothing -> Nothing;\r\n };\r\n bug _ = Nothing;\r\n}\r\n}}}\r\n\r\nYou'll need `-O` and `-ddump-hi` to trigger it.\r\n\r\n{{{\r\n$ stack exec -- ghc -O -ddump-hi -ddump-to-file Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tpprIfaceCo\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/12241Surprising constructor accumulation2019-07-07T18:27:00ZDavid FeuerSurprising constructor accumulation`containers` version 0.5.7.1 (and a few earlier versions) uses the following implementation of `fromList` by Ross Paterson:
```hs
fromList :: [a] -> Seq a
fromList = Seq . mkTree 1 . map_elem
where
{-# SPECIALIZE mkTree :: ...`containers` version 0.5.7.1 (and a few earlier versions) uses the following implementation of `fromList` by Ross Paterson:
```hs
fromList :: [a] -> Seq a
fromList = Seq . mkTree 1 . map_elem
where
{-# SPECIALIZE mkTree :: Int -> [Elem a] -> FingerTree (Elem a) #-}
{-# SPECIALIZE mkTree :: Int -> [Node a] -> FingerTree (Node a) #-}
mkTree :: (Sized a) => Int -> [a] -> FingerTree a
mkTree !_ [] = EmptyT
mkTree _ [x1] = Single x1
mkTree s [x1, x2] = Deep (2*s) (One x1) EmptyT (One x2)
mkTree s [x1, x2, x3] = Deep (3*s) (One x1) EmptyT (Two x2 x3)
mkTree s (x1:x2:x3:x4:xs) = case getNodes (3*s) x4 xs of
(ns, sf) -> case mkTree (3*s) ns of
!m -> Deep (3*size x1 + size m + size sf) (Three x1 x2 x3) m sf
getNodes :: Int -> a -> [a] -> ([Node a], Digit a)
getNodes !_ x1 [] = ([], One x1)
getNodes _ x1 [x2] = ([], Two x1 x2)
getNodes _ x1 [x2, x3] = ([], Three x1 x2 x3)
getNodes s x1 (x2:x3:x4:xs) = (Node3 s x1 x2 x3:ns, d)
where (ns, d) = getNodes s x4 xs
map_elem :: [a] -> [Elem a]
#if __GLASGOW_HASKELL__ >= 708
map_elem xs = coerce xs
#else
map_elem xs = Data.List.map Elem xs
#endif
{-# INLINE map_elem #-}
```
This uses one lazy list per "level" in the tree being constructed. I believe Paterson (and pretty much everyone else) expected that there would be `O(log n)` pair constructors and conses live at any given time. Wadler's technique in [Fixing some space leaks with a garbage collector](http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps.gz), which the GHC commentary indicates is used in GHC, should clean up the pairs in `getNodes`'s `d` thunks as they reach WHNF.
Lennart Spitzner dug into the unimpressive performance of the above code and using
```hs
main = evaluate $ S.fromList [(0::Int)..999999]
```
produced [this heap profile](http://heap.ezyang.com/view/72d4d1eb879a2085ffd49d270b03c7a037b4d5c2). If I'm reading it right, this suggests that there are lots of `(,)` and also `(:)` constructors live, more `O(n)` than `O(log n)`.
I had previously found that I could improve performance by building the intermediate lists strictly, but that violates the generational hypothesis and leads to a slow-down for very large arguments ([Spitzner's heap profile](http://heap.ezyang.com/view/2e80598f73d9281f5eadfeb041f5b9aef6e448b0)). Spitzner was able to come up with a very clever (but much trickier) implementation that skirted all these problems ([profile](http://heap.ezyang.com/view/7f1994c0417931360fe7c41bd995c37ebc3fd6c5)) and avoids ever allocating the troublesome pairs.
So the problem is thoroughly bypassed for `containers`, but it seems like something is not quite right here, and it might bear looking into.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Surprising constructor accumulation","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"`containers` version 0.5.7.1 (and a few earlier versions) uses the following implementation of `fromList` by Ross Paterson:\r\n\r\n{{{#!hs\r\nfromList :: [a] -> Seq a\r\nfromList = Seq . mkTree 1 . map_elem\r\n where\r\n {-# SPECIALIZE mkTree :: Int -> [Elem a] -> FingerTree (Elem a) #-}\r\n {-# SPECIALIZE mkTree :: Int -> [Node a] -> FingerTree (Node a) #-}\r\n mkTree :: (Sized a) => Int -> [a] -> FingerTree a\r\n mkTree !_ [] = EmptyT\r\n mkTree _ [x1] = Single x1\r\n mkTree s [x1, x2] = Deep (2*s) (One x1) EmptyT (One x2)\r\n mkTree s [x1, x2, x3] = Deep (3*s) (One x1) EmptyT (Two x2 x3)\r\n mkTree s (x1:x2:x3:x4:xs) = case getNodes (3*s) x4 xs of\r\n (ns, sf) -> case mkTree (3*s) ns of\r\n !m -> Deep (3*size x1 + size m + size sf) (Three x1 x2 x3) m sf\r\n\r\n getNodes :: Int -> a -> [a] -> ([Node a], Digit a)\r\n getNodes !_ x1 [] = ([], One x1)\r\n getNodes _ x1 [x2] = ([], Two x1 x2)\r\n getNodes _ x1 [x2, x3] = ([], Three x1 x2 x3)\r\n getNodes s x1 (x2:x3:x4:xs) = (Node3 s x1 x2 x3:ns, d)\r\n where (ns, d) = getNodes s x4 xs\r\n\r\n map_elem :: [a] -> [Elem a]\r\n#if __GLASGOW_HASKELL__ >= 708\r\n map_elem xs = coerce xs\r\n#else\r\n map_elem xs = Data.List.map Elem xs\r\n#endif\r\n {-# INLINE map_elem #-}\r\n}}}\r\n\r\nThis uses one lazy list per \"level\" in the tree being constructed. I believe Paterson (and pretty much everyone else) expected that there would be `O(log n)` pair constructors and conses live at any given time. Wadler's technique in [http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps.gz Fixing some space leaks with a garbage collector], which the GHC commentary indicates is used in GHC, should clean up the pairs in `getNodes`'s `d` thunks as they reach WHNF.\r\n\r\nLennart Spitzner dug into the unimpressive performance of the above code and using\r\n\r\n{{{#!hs\r\nmain = evaluate $ S.fromList [(0::Int)..999999]\r\n}}}\r\n\r\nproduced [http://heap.ezyang.com/view/72d4d1eb879a2085ffd49d270b03c7a037b4d5c2 this heap profile]. If I'm reading it right, this suggests that there are lots of `(,)` and also `(:)` constructors live, more `O(n)` than `O(log n)`.\r\n\r\nI had previously found that I could improve performance by building the intermediate lists strictly, but that violates the generational hypothesis and leads to a slow-down for very large arguments ([http://heap.ezyang.com/view/2e80598f73d9281f5eadfeb041f5b9aef6e448b0 Spitzner's heap profile]). Spitzner was able to come up with a very clever (but much trickier) implementation that skirted all these problems ([http://heap.ezyang.com/view/7f1994c0417931360fe7c41bd995c37ebc3fd6c5 profile]) and avoids ever allocating the troublesome pairs.\r\n\r\nSo the problem is thoroughly bypassed for `containers`, but it seems like something is not quite right here, and it might bear looking into.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12238Many tests fail when BuildFlavour == perf-llvm and DYNAMIC_GHC_PROGRAMS == NO2019-07-07T18:27:01ZerikdMany tests fail when BuildFlavour == perf-llvm and DYNAMIC_GHC_PROGRAMS == NOTicket spawned from #12230.
Some time just before commit a33b498d5f648a576dac6d219115866f05721196 about 40 tests started failing with `BuildFlavour` set to `perf-llvm`.
\@simonmar suggested also testing with `DYNAMIC_GHC_PROGRAMS` set ...Ticket spawned from #12230.
Some time just before commit a33b498d5f648a576dac6d219115866f05721196 about 40 tests started failing with `BuildFlavour` set to `perf-llvm`.
\@simonmar suggested also testing with `DYNAMIC_GHC_PROGRAMS` set to `NO` which results on over 700 of the tests failing.
\@simonmar suggests something is broken in the LLVM backend or in the linker.https://gitlab.haskell.org/ghc/ghc/-/issues/12237Constraint resolution vs. type family resolution vs. TypeErrors2019-07-07T18:27:01ZGergő ÉrdiConstraint resolution vs. type family resolution vs. TypeErrorsVia http://stackoverflow.com/q/37769351/477476, given the following setup:
```hs
{-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-}
{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, UndecidableInstances #-}
import Data.Proxy
i...Via http://stackoverflow.com/q/37769351/477476, given the following setup:
```hs
{-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-}
{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, UndecidableInstances #-}
import Data.Proxy
import GHC.TypeLits
type family TEq a b where
TEq a a = a
TEq a b = TypeError (Text "TEq error")
type family F a where
F () = ()
F (a, b) = TEq (F a) (F b)
F a = TypeError (Text "Unsupported type: " :<>: ShowType a)
```
and the following usages of `F` and `TEq`:
```hs
class (repr ~ F a) => C repr a
foo :: (C (F a) a) => proxy a -> ()
foo _ = ()
main :: IO ()
main = print $ foo (Proxy :: Proxy (Int, ()))
```
This results in
```
* No instance for (C (TEq (TypeError ...) ()) (Int, ()))
arising from a use of `foo'
* In the second argument of `($)', namely
`foo (Proxy :: Proxy (Int, ()))'
In the expression: print $ foo (Proxy :: Proxy (Int, ()))
In an equation for `main':
main = print $ foo (Proxy :: Proxy (Int, ()))
```
but it would be preferable to bail out earlier when `F Int` is resolved to `TypeError ...` instead of propagating that all the way to the `C` constraint.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Constraint resolution vs. type family resolution vs. TypeErrors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["CustomTypeErrors"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Via http://stackoverflow.com/q/37769351/477476, given the following setup:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-}\r\n{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, UndecidableInstances #-}\r\n\r\nimport Data.Proxy\r\nimport GHC.TypeLits\r\n\r\ntype family TEq a b where\r\n TEq a a = a\r\n TEq a b = TypeError (Text \"TEq error\")\r\n\r\ntype family F a where\r\n F () = ()\r\n F (a, b) = TEq (F a) (F b)\r\n F a = TypeError (Text \"Unsupported type: \" :<>: ShowType a)\r\n}}}\r\n\r\nand the following usages of `F` and `TEq`:\r\n\r\n{{{#!hs\r\nclass (repr ~ F a) => C repr a\r\n\r\nfoo :: (C (F a) a) => proxy a -> ()\r\nfoo _ = ()\r\n\r\nmain :: IO ()\r\nmain = print $ foo (Proxy :: Proxy (Int, ()))\r\n}}}\r\n\r\nThis results in\r\n\r\n{{{\r\n * No instance for (C (TEq (TypeError ...) ()) (Int, ()))\r\n arising from a use of `foo'\r\n * In the second argument of `($)', namely\r\n `foo (Proxy :: Proxy (Int, ()))'\r\n In the expression: print $ foo (Proxy :: Proxy (Int, ()))\r\n In an equation for `main':\r\n main = print $ foo (Proxy :: Proxy (Int, ()))\r\n}}}\r\n\r\nbut it would be preferable to bail out earlier when `F Int` is resolved to `TypeError ...` instead of propagating that all the way to the `C` constraint.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12235Wrong compilation of bang patterns2019-07-07T18:27:02ZÖmer Sinan AğacanWrong compilation of bang patternsI have this function:
```haskell
fn5 :: Int -> [T] -> Int
fn5 i [] = i
fn5 i (A : ts) = fn5 (i + 1) ts
fn5 !i (B : ts) = fn5 (i + 2) ts
fn5 i (C : ts) = fn5 0 ts
```
This function should only `seq` the int after seeing that head of the...I have this function:
```haskell
fn5 :: Int -> [T] -> Int
fn5 i [] = i
fn5 i (A : ts) = fn5 (i + 1) ts
fn5 !i (B : ts) = fn5 (i + 2) ts
fn5 i (C : ts) = fn5 0 ts
```
This function should only `seq` the int after seeing that head of the list is `B`. But this is the generated code: (desugar)
```
Rec {
-- RHS size: {terms: 64, types: 33, coercions: 0}
fn5 [Occ=LoopBreaker] :: Int -> [T] -> Int
[LclIdX, Str=DmdType]
fn5 =
\ (i_ayA :: Int) (ds_d1Zb :: [T]) ->
let {
fail_d1Zn :: GHC.Prim.Void# -> Int
[LclId, Str=DmdType]
fail_d1Zn =
\ _ [Occ=Dead, OS=OneShot] ->
Control.Exception.Base.patError
@ 'GHC.Types.PtrRepLifted
@ Int
"Main.hs:(41,1)-(44,25)|function fn5"# } in
case ds_d1Zb of _ [Occ=Dead] {
[] -> i_ayA;
: ds_d1Zk ts_ayC ->
case ds_d1Zk of _ [Occ=Dead] {
__DEFAULT ->
(\ _ [Occ=Dead, OS=OneShot] ->
let {
fail_d1Zp :: GHC.Prim.Void# -> Int
[LclId, Str=DmdType]
fail_d1Zp =
\ _ [Occ=Dead, OS=OneShot] ->
case ds_d1Zb of _ [Occ=Dead] {
__DEFAULT -> fail_d1Zn GHC.Prim.void#;
: ds_d1Zm ts_ayG ->
case ds_d1Zm of _ [Occ=Dead] {
__DEFAULT -> fail_d1Zn GHC.Prim.void#;
C -> fn5 (GHC.Types.I# 0#) ts_ayG
}
} } in
case i_ayA of i_XyO { __DEFAULT ->
case ds_d1Zb of _ [Occ=Dead] {
__DEFAULT -> fail_d1Zp GHC.Prim.void#;
: ds_d1Zl ts_ayE ->
case ds_d1Zl of _ [Occ=Dead] {
__DEFAULT -> fail_d1Zp GHC.Prim.void#;
B -> fn5 (+ @ Int GHC.Num.$fNumInt i_XyO (GHC.Types.I# 2#)) ts_ayE
}
}
})
GHC.Prim.void#;
A -> fn5 (+ @ Int GHC.Num.$fNumInt i_ayA (GHC.Types.I# 1#)) ts_ayC
}
}
end Rec }
```
This code evaluates the list, and evaluates the int unless head of the list is `A`. I don't know why there's special case in A? In any case, this is wrong behavior as it forces the int in wrong times. As an example, this fails:
```haskell
data T = A | B | C
fn5 :: Int -> [T] -> Int
fn5 i [] = i
fn5 i (A : ts) = fn5 (i + 1) ts
fn5 !i (B : ts) = fn5 (i + 2) ts
fn5 i (C : ts) = fn5 0 ts
main = print (fn5 undefined [C])
```
Tried with: GHC HEAD, 8.0.1.https://gitlab.haskell.org/ghc/ghc/-/issues/12234'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM2019-07-07T18:27:02ZSergei Trofimovich'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAMThe example is slimmed down unit test of Annotations-0.2.1 hackage package.
If we try to compile Bug.hs with -O0 it compiles quickly.
Trying it with -O1 makes GHC-8.0.1 takes a minute to finish.
```hs
-- Bug1.hs:
{-# LANGUAGE Standalon...The example is slimmed down unit test of Annotations-0.2.1 hackage package.
If we try to compile Bug.hs with -O0 it compiles quickly.
Trying it with -O1 makes GHC-8.0.1 takes a minute to finish.
```hs
-- Bug1.hs:
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug () where
import Prelude (Eq)
data ExprF rT = ExprF rT rT deriving Eq
newtype Expr = Expr (Fix ExprF) deriving Eq
newtype Fix fT = In (fT (Fix fT))
deriving instance Eq (f (Fix f)) => Eq (Fix f)
```
```
$ time ghc-8.0.1 -c -O0 Bug1.hs -fforce-recomp
real 0m0.611s
user 0m0.549s
sys 0m0.053s
$ time ghc-8.0.1 -c -O1 Bug1.hs -fforce-recomp
real 1m2.199s
user 1m1.676s
sys 0m0.465s
```
1. 10.2 for comparison is very quick in both O0/O1:
```
$ time ghc-7.10.2 -c -O0 Bug1.hs -fforce-recomp
real 0m0.220s
user 0m0.183s
sys 0m0.036s
$ time ghc-7.10.2 -c -O1 Bug1.hs -fforce-recomp
real 0m0.237s
user 0m0.213s
sys 0m0.023s
```
The real ExprF datatype uses more constructors and instances:
```
data ExprF rT
= Add rT rT
| Sub rT rT
| Mul rT rT
| Div rT rT
| Num Int
deriving (Eq, Show)
```
That requires a lot of time and space to finish (Bug2.hs in attach).
I've stopped it after 5 minutes (took \~8GB RAM).8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12233Compilation does not stop on XeTeX error2019-07-07T18:27:03ZmarkusrCompilation does not stop on XeTeX errorShort: This bug is important for building in an automated manner, because an error in the documentations Tex code currently results in an interactive shell.
I am compiling GHC 8.0.1 and the build system picked up XeTeX, which results in...Short: This bug is important for building in an automated manner, because an error in the documentations Tex code currently results in an interactive shell.
I am compiling GHC 8.0.1 and the build system picked up XeTeX, which results in compilation of a PDF. There is a syntax error in the Tex code. Unfortunately, xelatex is called without the `-halt-on-error` option and compilation just sits there in the interactive xelatex promt.
```
[...]
generating indices... genindexcd docs/users_guide/build-pdf/users_guide ; xelatex users_guide.tex
writing additional pages... searchThis is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/Exherbo texlive-core-2
015-r2) (preloaded format=xelatex)
restricted \write18 enabled.
copying images... [100%] images/prof_scc.svg
copying static files... done
copying extra files... done
dumping search index in English (code: en) ... done
dumping object inventory... done
build succeeded, 25 warnings.
entering extended mode
(./users_guide.tex
LaTeX2e <2015/01/01>
Babel <3.9l> and hyphenation patterns for 79 languages loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texmf-dist/tex/latex/base/size10.clo)))
(/usr/share/texmf-dist/tex/generic/iftex/iftex.sty)
(/usr/share/texmf-dist/tex/latex/cmap/cmap.sty
Package cmap Warning: pdftex not detected - exiting.
) (/usr/share/texmf-dist/tex/latex/base/fontenc.sty
[...]
LaTeX Warning: Reference `glasgow_exts:ghc-flag--XIncoherentInstances' on page
285 undefined on input line 26759.
! Missing \endcsname inserted.
<to be read again>
\let
l.26762 \begin{Verbatim}[commandchars=\\\{\}]
?
```
Please consider adding `-halt-on-error` in rules/sphinx.mk. Attached is a patch for master.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Compilation does not stop on XeTeX error","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Short: This bug is important for building in an automated manner, because an error in the documentations Tex code currently results in an interactive shell.\r\n\r\nI am compiling GHC 8.0.1 and the build system picked up XeTeX, which results in compilation of a PDF. There is a syntax error in the Tex code. Unfortunately, xelatex is called without the `-halt-on-error` option and compilation just sits there in the interactive xelatex promt.\r\n\r\n{{{\r\n[...]\r\ngenerating indices... genindexcd docs/users_guide/build-pdf/users_guide ; xelatex users_guide.tex\r\n\r\nwriting additional pages... searchThis is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/Exherbo texlive-core-2\r\n015-r2) (preloaded format=xelatex)\r\n restricted \\write18 enabled.\r\n\r\ncopying images... [100%] images/prof_scc.svg \r\ncopying static files... done\r\ncopying extra files... done\r\ndumping search index in English (code: en) ... done\r\ndumping object inventory... done\r\nbuild succeeded, 25 warnings.\r\nentering extended mode\r\n(./users_guide.tex\r\nLaTeX2e <2015/01/01>\r\nBabel <3.9l> and hyphenation patterns for 79 languages loaded.\r\n(./sphinxmanual.cls\r\nDocument Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)\r\n(/usr/share/texmf-dist/tex/latex/base/report.cls\r\nDocument Class: report 2014/09/29 v1.4h Standard LaTeX document class\r\n(/usr/share/texmf-dist/tex/latex/base/size10.clo)))\r\n(/usr/share/texmf-dist/tex/generic/iftex/iftex.sty)\r\n(/usr/share/texmf-dist/tex/latex/cmap/cmap.sty\r\n\r\nPackage cmap Warning: pdftex not detected - exiting.\r\n\r\n) (/usr/share/texmf-dist/tex/latex/base/fontenc.sty\r\n[...]\r\nLaTeX Warning: Reference `glasgow_exts:ghc-flag--XIncoherentInstances' on page \r\n285 undefined on input line 26759.\r\n\r\n! Missing \\endcsname inserted.\r\n<to be read again> \r\n \\let \r\nl.26762 \\begin{Verbatim}[commandchars=\\\\\\{\\}]\r\n \r\n?\r\n}}}\r\n\r\nPlease consider adding `-halt-on-error` in rules/sphinx.mk. Attached is a patch for master.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12230Non-deterministic ghc-iserv terminated error2019-07-07T18:27:04ZEdward Z. YangNon-deterministic ghc-iserv terminated errorI noticed on a recent validate that I have been getting non-deterministic test failures due to external interpreter:
```
=====> T10891(ext-interp) 12 of 15 [0, 1, 0] [77/9256]
cd "./th/T10...I noticed on a recent validate that I have been getting non-deterministic test failures due to external interpreter:
```
=====> T10891(ext-interp) 12 of 15 [0, 1, 0] [77/9256]
cd "./th/T10891.run" && "/home/hs01/ezyang/ghc-validate/inplace/test spaces/ghc-stage2" -c T10891.h
s -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisatio
ns -fshow-warning-groups -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 > T108
91.comp.stderr 2>&1
Compile failed (exit code 1) errors were:
T10891.hs:30:3: error:
• Exception when trying to run compile-time code:
ghc-stage2: ghc-iserv terminated (-11)
Code: let
display :: Name -> Q ()
display q = ...
in
do { display ''C;
display ''C';
.... }
• In the untyped splice:
$(let
display :: Name -> Q ()
display q = do { ... }
in
do { display ''C;
display ''C';
display ''C'';
.... })
```
More tests error the higher I crank up parallelism; on a recent full test run I got something like twenty failures of this kind when I have twelve threads.
There are at least two problems here. The first is the actual failure, but the second is that there isn't enough diagnostic information here to tell what the actual problem is. Combined with the nondeterministic nature of this bug I'm not sure how to debug it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Non-deterministic ghc-iserv terminated error","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I noticed on a recent validate that I have been getting non-deterministic test failures due to external interpreter:\r\n\r\n{{{\r\n=====> T10891(ext-interp) 12 of 15 [0, 1, 0] [77/9256]\r\ncd \"./th/T10891.run\" && \"/home/hs01/ezyang/ghc-validate/inplace/test spaces/ghc-stage2\" -c T10891.h\r\ns -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisatio\r\nns -fshow-warning-groups -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 > T108\r\n91.comp.stderr 2>&1\r\nCompile failed (exit code 1) errors were:\r\n\r\nT10891.hs:30:3: error:\r\n • Exception when trying to run compile-time code:\r\n ghc-stage2: ghc-iserv terminated (-11)\r\n Code: let\r\n display :: Name -> Q ()\r\n display q = ...\r\n in\r\n do { display ''C;\r\n display ''C';\r\n .... }\r\n • In the untyped splice:\r\n $(let\r\n display :: Name -> Q ()\r\n display q = do { ... }\r\n in\r\n do { display ''C;\r\n display ''C';\r\n display ''C'';\r\n .... })\r\n}}}\r\n\r\nMore tests error the higher I crank up parallelism; on a recent full test run I got something like twenty failures of this kind when I have twelve threads.\r\n\r\nThere are at least two problems here. The first is the actual failure, but the second is that there isn't enough diagnostic information here to tell what the actual problem is. Combined with the nondeterministic nature of this bug I'm not sure how to debug it.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/12229Narrow the scope of record wildcards notation slightly2019-07-07T18:27:04ZSimon Peyton JonesNarrow the scope of record wildcards notation slightlyAs fallout from #12130 I narrowed the scope of record-wildcard notation slightly. Here's the commit
```
commit 2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Thu Jun 23 09:02:00 2016 ...As fallout from #12130 I narrowed the scope of record-wildcard notation slightly. Here's the commit
```
commit 2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Thu Jun 23 09:02:00 2016 +0100
Narrow the use of record wildcards slightly
In reviewing the fix to Trac #12130 I found the wild-card
fill-in code for ".." notation in record constructions hard
to understand. It went to great contortions (including the
find_tycon code) to allow
data T = C { x, y :: Int }
f x = C { .. }
to expand to
f x = C { x = x, y = y }
where 'y' is an /imported function/! That seems way over the top
for what record wildcards are supposed to do.
So I have narrowed the record-wildcard expansion to include only
/locally-bound/ variables; i.e. not top level, and certainly not
imported.
I don't think anyone is using record wildcards in this bizarre way, so
I don't expect any fallout. Even if there is, you can easily
initialise fields with eponymous but imported values by hand.
An intermediate position would be to allow /local/ top-level
definitions. But I doubt anyone is doing that either.
Let's see if there's any fallout. It's a local change, easy to
revert, so I've just gone ahead to save everyone's time.
```
This ticket can be used for any commentary. I've also added a test.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Narrow the scope of record wildcards notation slightly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As fallout from #12130 I narrowed the scope of record-wildcard notation slightly. Here's the commit\r\n{{{\r\ncommit 2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\nDate: Thu Jun 23 09:02:00 2016 +0100\r\n\r\n Narrow the use of record wildcards slightly\r\n \r\n In reviewing the fix to Trac #12130 I found the wild-card\r\n fill-in code for \"..\" notation in record constructions hard\r\n to understand. It went to great contortions (including the\r\n find_tycon code) to allow\r\n data T = C { x, y :: Int }\r\n f x = C { .. }\r\n to expand to\r\n f x = C { x = x, y = y }\r\n where 'y' is an /imported function/! That seems way over the top\r\n for what record wildcards are supposed to do.\r\n \r\n So I have narrowed the record-wildcard expansion to include only\r\n /locally-bound/ variables; i.e. not top level, and certainly not\r\n imported.\r\n \r\n I don't think anyone is using record wildcards in this bizarre way, so\r\n I don't expect any fallout. Even if there is, you can easily\r\n initialise fields with eponymous but imported values by hand.\r\n \r\n An intermediate position would be to allow /local/ top-level\r\n definitions. But I doubt anyone is doing that either.\r\n \r\n Let's see if there's any fallout. It's a local change, easy to\r\n revert, so I've just gone ahead to save everyone's time.\r\n}}}\r\nThis ticket can be used for any commentary. I've also added a test.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12228Make newtype polykinded2019-07-07T18:27:04ZDavid FeuerMake newtype polykindedI hate having to give up so much top type safety when I use unlifted types. It seems to me that I should be able to use `newtype` to create new types of kind `#` as well as `*`:
```hs
newtype MyWord# = MyWord# Word#
newtype GoodStuff# a...I hate having to give up so much top type safety when I use unlifted types. It seems to me that I should be able to use `newtype` to create new types of kind `#` as well as `*`:
```hs
newtype MyWord# = MyWord# Word#
newtype GoodStuff# a = GoodStuff (# Int#, a #)
```
In an ideal world, such types would be in Core (so RULES could see them), but I'd be very happy even to just have them in Haskell.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| 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":"Make newtype polykinded","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I hate having to give up so much top type safety when I use unlifted types. It seems to me that I should be able to use `newtype` to create new types of kind `#` as well as `*`:\r\n\r\n{{{#!hs\r\nnewtype MyWord# = MyWord# Word#\r\nnewtype GoodStuff# a = GoodStuff (# Int#, a #)\r\n}}}\r\n\r\nIn an ideal world, such types would be in Core (so RULES could see them), but I'd be very happy even to just have them in Haskell.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12227regression: out of memory with -O2 -ddump-hi on a complex INLINE function2019-07-07T18:27:04Zj6careyregression: out of memory with -O2 -ddump-hi on a complex INLINE functionSummary:
Unlike GHC 7.10.2, when GHC 8.0.1 tries to compile a certain complex INLINE function with -O2 -ddump-hi, it runs out of memory. Dropping either -O2 or -ddump-hi enables successful compilation.
Oddly enough, triggering the issu...Summary:
Unlike GHC 7.10.2, when GHC 8.0.1 tries to compile a certain complex INLINE function with -O2 -ddump-hi, it runs out of memory. Dropping either -O2 or -ddump-hi enables successful compilation.
Oddly enough, triggering the issue requires using the function argument indirectly through a variable bound by a "where" clause, even though it is obvious to a human reader that the indirection is trivial.
(Even after simplifying the original code to work around the out of memory issue, that indirection greatly increases the size of the ".dump-hi" file. It might be that the "out of memory" would not happen if one had sufficient RAM.)
Using INLINABLE instead of INLINE seems to result in a much smaller RHS being recorded for the function in question, and does not trigger the problem. (Perhaps INLINABLE records a more optimized RHS than does INLINE, though that is not obvious to me from the GHC User's Guide.)
The attached files contain a reduced version of the original code that still triggers the problem. (Of course, the reduced version is rather artificial and pointless, other than to demonstrate the problem.) Probably someone with sufficient understanding could shrink the example further.
Please note that I have worked around the issue, and so I am not blocked by this problem, at least not currently.
Attachments:
- crash.bash
- Crash.hs
Observed behavior:
On 64-bit x86 Ubuntu 16.04 LTS, with the attached files in the current directory, GHC 7.10.2 succeeds:
```
$ ./crash.bash
The Glorious Glasgow Haskell Compilation System, version 7.10.2
[1 of 1] Compiling Crash ( Crash.hs, Crash.o )
```
whereas GHC 8.0.1 runs out of memory (or wedges my system if I comment out both "ulimit" commands in the script):
```
$ ./crash.bash
The Glorious Glasgow Haskell Compilation System, version 8.0.1
[1 of 1] Compiling Crash ( Crash.hs, Crash.o )
ghc: out of memory
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"regression: out of memory with -O2 -ddump-hi on a complex INLINE function","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Summary:\r\n\r\nUnlike GHC 7.10.2, when GHC 8.0.1 tries to compile a certain complex INLINE function with -O2 -ddump-hi, it runs out of memory. Dropping either -O2 or -ddump-hi enables successful compilation.\r\n\r\nOddly enough, triggering the issue requires using the function argument indirectly through a variable bound by a \"where\" clause, even though it is obvious to a human reader that the indirection is trivial.\r\n\r\n(Even after simplifying the original code to work around the out of memory issue, that indirection greatly increases the size of the \".dump-hi\" file. It might be that the \"out of memory\" would not happen if one had sufficient RAM.)\r\n\r\nUsing INLINABLE instead of INLINE seems to result in a much smaller RHS being recorded for the function in question, and does not trigger the problem. (Perhaps INLINABLE records a more optimized RHS than does INLINE, though that is not obvious to me from the GHC User's Guide.)\r\n\r\nThe attached files contain a reduced version of the original code that still triggers the problem. (Of course, the reduced version is rather artificial and pointless, other than to demonstrate the problem.) Probably someone with sufficient understanding could shrink the example further.\r\n\r\nPlease note that I have worked around the issue, and so I am not blocked by this problem, at least not currently.\r\n\r\nAttachments:\r\n\r\n- crash.bash\r\n\r\n- Crash.hs\r\n\r\nObserved behavior:\r\n\r\nOn 64-bit x86 Ubuntu 16.04 LTS, with the attached files in the current directory, GHC 7.10.2 succeeds:\r\n{{{\r\n$ ./crash.bash\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.2\r\n[1 of 1] Compiling Crash ( Crash.hs, Crash.o )\r\n}}}\r\nwhereas GHC 8.0.1 runs out of memory (or wedges my system if I comment out both \"ulimit\" commands in the script):\r\n{{{\r\n$ ./crash.bash\r\nThe Glorious Glasgow Haskell Compilation System, version 8.0.1\r\n[1 of 1] Compiling Crash ( Crash.hs, Crash.o )\r\nghc: out of memory\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2