GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:06:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2767Type family bug ?2019-07-07T19:06:58ZtestType family bug ?I get this error when compiling a program with associated type families:
```
$ ghc --make Queens_v2.hs
[1 of 5] Compiling Domain ( Domain.hs, Domain.o )
[2 of 5] Compiling Solver ( Solver.hs, Solver.o )
[3 of 5] Com...I get this error when compiling a program with associated type families:
```
$ ghc --make Queens_v2.hs
[1 of 5] Compiling Domain ( Domain.hs, Domain.o )
[2 of 5] Compiling Solver ( Solver.hs, Solver.o )
[3 of 5] Compiling FD ( FD.hs, FD.o )
[4 of 5] Compiling SearchTree ( SearchTree.hs, SearchTree.o )
[5 of 5] Compiling Main ( Queens_v2.hs, Queens_v2.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
idInfo co{v a629} [tv]
```
Tom Schrijvers
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type family bug ?","status":"New","operating_system":"MacOS X","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I get this error when compiling a program with associated type families:\r\n{{{\r\n$ ghc --make Queens_v2.hs \r\n[1 of 5] Compiling Domain ( Domain.hs, Domain.o )\r\n[2 of 5] Compiling Solver ( Solver.hs, Solver.o )\r\n[3 of 5] Compiling FD ( FD.hs, FD.o )\r\n[4 of 5] Compiling SearchTree ( SearchTree.hs, SearchTree.o )\r\n[5 of 5] Compiling Main ( Queens_v2.hs, Queens_v2.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tidInfo co{v a629} [tv]\r\n}}}\r\n\r\nTom Schrijvers","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2800deprecated OPTIONS flag warnings generated during dep chasing?2019-07-07T19:06:47Zduncandeprecated OPTIONS flag warnings generated during dep chasing?It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing.
`ghc --make` has to scan each mo...It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing.
`ghc --make` has to scan each module to look for options and language extensions to know if it has to run cpp. At this stage it cannot of course run cpp so it does not necessarily get the full set of options and extensions since some may be conditional. So it should not at this stage generate any warnings since they may be suppressed by later cpp-conditional flags.
Another possible theory is that it generates the warnings before having read all the `OPTIONS` flags so the later warning suppression is ineffective. Unfortunately we have to put them in the order we do for compatibility with older versions of ghc.
Here's an example out of Cabal:
```
{-# OPTIONS -cpp -fffi #-}
-- OPTIONS required for ghc-6.4.x, and must appear first
{-# LANGUAGE CPP, ForeignFunctionInterface #-}
{-# OPTIONS_GHC -cpp -fffi #-}
{-# OPTIONS_NHC98 -cpp #-}
{-# OPTIONS_JHC -fcpp -fffi #-}
#if __GLASGOW_HASKELL__ >= 610
{-# OPTIONS_GHC -fno-warn-deprecated-flags #-}
-- the ghc flag -fffi is deprecated in ghc-6.10. We're
-- supposed to use the LANGUAGE pragmas instead. However
-- we have to maintain compatibility with older ghc versions
-- so we (try to) suppress this warning.
#endif
```
What we're trying to do here is make it work with ghc-6.4 + and not generate any warnings with the latest ghc. This seems quite tricky to do.
To support ghc-6.4 we have to put the `OPTIONS` pragma first, since it apparently only looks at the first couple lines. We then use the compiler-specific `OPTIONS` pragmas. In particular these are needed for ghc-6.6. For ghc-6.8 and later we can use the `LANGUAGE` pragmas.
In ghc-6.10 the `-fffi` option is deprecated. However we cannot conditionally compile the `OPTIONS -cpp -fffi` since ghc needs to see the `-cpp` to know that it has to cpp the module. Making the `OPTIONS -cpp` unconditional and the `OPTIONS -cpp -fffi` conditional does not work with ghc-6.4.
So instead we try suppressing the warning. We cannot do that unconditionally since the flag is only present in newer ghc versions. However if we do suppress conditionally then ghc still warns anyway, presumably because it is warning on the first pass rather than in the pass after running cpp.
All in all it's a bit tricky to do right. Indeed I cannot currently see a way to make it work at all without generating warnings. The sledgehammer would be to put a flag in the .cabal file and have it apply to all modules, however that does not prevent the warning happening during Cabal bootstrapping which uses plain `ghc --make`.
<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":"deprecated OPTIONS flag warnings generated during dep chasing?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing.\r\n\r\n`ghc --make` has to scan each module to look for options and language extensions to know if it has to run cpp. At this stage it cannot of course run cpp so it does not necessarily get the full set of options and extensions since some may be conditional. So it should not at this stage generate any warnings since they may be suppressed by later cpp-conditional flags.\r\n\r\nAnother possible theory is that it generates the warnings before having read all the `OPTIONS` flags so the later warning suppression is ineffective. Unfortunately we have to put them in the order we do for compatibility with older versions of ghc.\r\n\r\nHere's an example out of Cabal:\r\n\r\n{{{\r\n{-# OPTIONS -cpp -fffi #-}\r\n-- OPTIONS required for ghc-6.4.x, and must appear first\r\n{-# LANGUAGE CPP, ForeignFunctionInterface #-}\r\n{-# OPTIONS_GHC -cpp -fffi #-}\r\n{-# OPTIONS_NHC98 -cpp #-}\r\n{-# OPTIONS_JHC -fcpp -fffi #-}\r\n#if __GLASGOW_HASKELL__ >= 610\r\n{-# OPTIONS_GHC -fno-warn-deprecated-flags #-}\r\n-- the ghc flag -fffi is deprecated in ghc-6.10. We're\r\n-- supposed to use the LANGUAGE pragmas instead. However\r\n-- we have to maintain compatibility with older ghc versions\r\n-- so we (try to) suppress this warning.\r\n#endif\r\n}}}\r\n\r\nWhat we're trying to do here is make it work with ghc-6.4 + and not generate any warnings with the latest ghc. This seems quite tricky to do.\r\n\r\nTo support ghc-6.4 we have to put the `OPTIONS` pragma first, since it apparently only looks at the first couple lines. We then use the compiler-specific `OPTIONS` pragmas. In particular these are needed for ghc-6.6. For ghc-6.8 and later we can use the `LANGUAGE` pragmas.\r\n\r\nIn ghc-6.10 the `-fffi` option is deprecated. However we cannot conditionally compile the `OPTIONS -cpp -fffi` since ghc needs to see the `-cpp` to know that it has to cpp the module. Making the `OPTIONS -cpp` unconditional and the `OPTIONS -cpp -fffi` conditional does not work with ghc-6.4. \r\n\r\nSo instead we try suppressing the warning. We cannot do that unconditionally since the flag is only present in newer ghc versions. However if we do suppress conditionally then ghc still warns anyway, presumably because it is warning on the first pass rather than in the pass after running cpp.\r\n\r\nAll in all it's a bit tricky to do right. Indeed I cannot currently see a way to make it work at all without generating warnings. The sledgehammer would be to put a flag in the .cabal file and have it apply to all modules, however that does not prevent the warning happening during Cabal bootstrapping which uses plain `ghc --make`.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2809Patching libffi fails in Solaris2019-07-07T19:06:44Zrl@cse.unsw.edu.auPatching libffi fails in SolarisThis is what happens:
```
gmake[1]: Entering directory `/home/rl/ghc/ghc/libffi'
rm -f -rf libffi-3.0.6 build
/usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz
mv libffi-3.0.6 build
chmod +x ln
patch -p0 < libffi-dllize-3.0.6.patch
Looks lik...This is what happens:
```
gmake[1]: Entering directory `/home/rl/ghc/ghc/libffi'
rm -f -rf libffi-3.0.6 build
/usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz
mv libffi-3.0.6 build
chmod +x ln
patch -p0 < libffi-dllize-3.0.6.patch
Looks like a unified context diff.
Hunk #5 failed at line 344.
Hunk #6 failed at line 165.
Hunk #7 failed at line 33.
3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej
The next patch looks like a unified context diff.
Hunk #2 failed at line 66.
Hunk #3 failed at line 26.
2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej
done
gmake[1]: *** [stamp.ffi.configure] Error 1
```
Using GNU `patch` instead of the Solaris version works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Patching libffi fails in Solaris","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is what happens:\r\n{{{\r\ngmake[1]: Entering directory `/home/rl/ghc/ghc/libffi'\r\nrm -f -rf libffi-3.0.6 build\r\n/usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz\r\nmv libffi-3.0.6 build\r\nchmod +x ln\r\npatch -p0 < libffi-dllize-3.0.6.patch\r\n Looks like a unified context diff.\r\nHunk #5 failed at line 344.\r\nHunk #6 failed at line 165.\r\nHunk #7 failed at line 33.\r\n3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej\r\n The next patch looks like a unified context diff.\r\nHunk #2 failed at line 66.\r\nHunk #3 failed at line 26.\r\n2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej\r\ndone\r\ngmake[1]: *** [stamp.ffi.configure] Error 1\r\n}}}\r\n\r\nUsing GNU `patch` instead of the Solaris version works.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2810Debugger: change context to the module containing the current breakpoint2019-07-07T19:06:44ZSimon MarlowDebugger: change context to the module containing the current breakpointMoved part of #2740 here.
When we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which th...Moved part of #2740 here.
When we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which the breakpoint expression is located.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Debugger: change context to the module containing the current breakpoint","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Moved part of #2740 here.\r\n\r\nWhen we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which the breakpoint expression is located.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2813Create a utf8 bytestring-a-like2019-07-07T19:06:43ZIan Lynagh <igloo@earth.li>Create a utf8 bytestring-a-likeThere are a number of things we want a utf8 bytestring-a-like for:
- GHC's !FastString to be built on top of
- Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)
- template haskell, to use in place of packedstring
- pos...There are a number of things we want a utf8 bytestring-a-like for:
- GHC's !FastString to be built on top of
- Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)
- template haskell, to use in place of packedstring
- possibly to use in the base IO libraries (see also #2811)
- possibly to use in haskeline (see also #2812)
and probably more besides. Ideally all of this will be done comfortably in time for 6.12!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Create a utf8 bytestring-a-like","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There are a number of things we want a utf8 bytestring-a-like for:\r\n * GHC's !FastString to be built on top of\r\n * Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)\r\n * template haskell, to use in place of packedstring\r\n * possibly to use in the base IO libraries (see also #2811)\r\n * possibly to use in haskeline (see also #2812)\r\nand probably more besides. Ideally all of this will be done comfortably in time for 6.12!\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2828TcTyFuns.uMeta: normalisation shouldn't allow x ~ x2019-07-07T19:06:39ZpizzaTcTyFuns.uMeta: normalisation shouldn't allow x ~ x```
pizza@extracheese:~/proj/truegraph$ ghci stats.hs
GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package b...```
pizza@extracheese:~/proj/truegraph$ ghci stats.hs
GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( stats.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.0.20081007 for i386-unknown-linux):
TcTyFuns.uMeta: normalisation shouldn't allow x ~ x
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
where stats.hs is:
```
mean :: (Num b) => [a] -> (a -> b) -> b
mean set f =
let total = sum $ map f set
mean' = total / fromIntegral $ length set
in mean'
```
NOTE that i'm not even sure if this code is correct or makes sense, i'm in the middle of growing it.
<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":"TcTyFuns.uMeta: normalisation shouldn't allow x ~ x","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":"{{{\r\npizza@extracheese:~/proj/truegraph$ ghci stats.hs \r\nGHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( stats.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.0.20081007 for i386-unknown-linux):\r\n TcTyFuns.uMeta: normalisation shouldn't allow x ~ x\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\n}}}\r\n\r\nwhere stats.hs is:\r\n\r\n{{{\r\nmean :: (Num b) => [a] -> (a -> b) -> b\r\nmean set f = \r\n let total = sum $ map f set \r\n mean' = total / fromIntegral $ length set \r\n in mean'\r\n}}}\r\n\r\nNOTE that i'm not even sure if this code is correct or makes sense, i'm in the middle of growing it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2844incorrect results when not compiling with optimisation2019-07-07T19:06:36ZIan Lynagh <igloo@earth.li>incorrect results when not compiling with optimisationThis is a cut-down `random1283`.
`R.hs`:
```
module R (randomIO) where
class Num a => Random a where
randomIO :: IO a
instance Random Int where
randomIO = return 10003
```
`s.hs`:
```
import R
main :: IO ()
main = do r >>=...This is a cut-down `random1283`.
`R.hs`:
```
module R (randomIO) where
class Num a => Random a where
randomIO :: IO a
instance Random Int where
randomIO = return 10003
```
`s.hs`:
```
import R
main :: IO ()
main = do r >>= print
r >>= print
r :: IO Int
r = randomIO
```
```
$ rm *.o *.hi s
$ ghc -c R.hs
$ ghc s.hs R.o -o s
$ ./s
-4611686018427387865
-4611686018427387865
$ rm *.o *.hi s
$ ghc -c R.hs
$ ghc s.hs R.o -o s -O
$ ./s
10003
10003
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.11.20081205
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"incorrect results when not compiling with optimisation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a cut-down `random1283`.\r\n\r\n`R.hs`:\r\n{{{\r\nmodule R (randomIO) where\r\n\r\nclass Num a => Random a where\r\n randomIO :: IO a\r\n\r\ninstance Random Int where\r\n randomIO = return 10003\r\n}}}\r\n\r\n`s.hs`:\r\n{{{\r\nimport R\r\n\r\nmain :: IO ()\r\nmain = do r >>= print\r\n r >>= print\r\n\r\nr :: IO Int\r\nr = randomIO\r\n}}}\r\n\r\n{{{\r\n$ rm *.o *.hi s\r\n$ ghc -c R.hs\r\n$ ghc s.hs R.o -o s\r\n$ ./s\r\n-4611686018427387865\r\n-4611686018427387865\r\n$ rm *.o *.hi s\r\n$ ghc -c R.hs\r\n$ ghc s.hs R.o -o s -O\r\n$ ./s\r\n10003\r\n10003\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.11.20081205\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2845break018 skips a step2019-07-07T19:06:35ZIan Lynagh <igloo@earth.li>break018 skips a stepThe `break018` test is failing:
```
@@ -1,13 +1,11 @@
Stopped at ../mdo.hs:(29,0)-(31,26)
-_result :: IO (N a) = _
-Stopped at ../mdo.hs:(29,15)-(31,26)
-_result :: IO (N Char) = _
-x :: Char = 'h'
-xs :: [Char] = _
+_result :: (# GHC....The `break018` test is failing:
```
@@ -1,13 +1,11 @@
Stopped at ../mdo.hs:(29,0)-(31,26)
-_result :: IO (N a) = _
-Stopped at ../mdo.hs:(29,15)-(31,26)
-_result :: IO (N Char) = _
-x :: Char = 'h'
-xs :: [Char] = _
+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _
Stopped at ../mdo.hs:29:29-41
_result :: IO (N Char) = _
f :: N Char = _
l :: N Char = _
x :: Char = 'h'
Stopped at ../mdo.hs:(7,0)-(8,41)
-_result :: IO (N a) = _
+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _
+Stopped at ../mdo.hs:7:25-38
+_result :: IO (IORef Bool) = _
*** unexpected failure for break018(ghci)
```
What's happening here is that as we `:st` through the evaluation we aren't stopping at the `mdo` expression any more; we go straight from the entire `l2dll` to the `newNode` expression:
```
l2dll :: [a] -> IO (N a)
l2dll (x:xs) = mdo c <- newNode l x f
(f, l) <- l2dll' c xs
return c
```
<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":"break018 skips a step","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `break018` test is failing:\r\n{{{\r\n@@ -1,13 +1,11 @@\r\n Stopped at ../mdo.hs:(29,0)-(31,26)\r\n-_result :: IO (N a) = _\r\n-Stopped at ../mdo.hs:(29,15)-(31,26)\r\n-_result :: IO (N Char) = _\r\n-x :: Char = 'h'\r\n-xs :: [Char] = _\r\n+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _\r\n Stopped at ../mdo.hs:29:29-41\r\n _result :: IO (N Char) = _\r\n f :: N Char = _\r\n l :: N Char = _\r\n x :: Char = 'h'\r\n Stopped at ../mdo.hs:(7,0)-(8,41)\r\n-_result :: IO (N a) = _\r\n+_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _\r\n+Stopped at ../mdo.hs:7:25-38\r\n+_result :: IO (IORef Bool) = _\r\n*** unexpected failure for break018(ghci)\r\n}}}\r\nWhat's happening here is that as we `:st` through the evaluation we aren't stopping at the `mdo` expression any more; we go straight from the entire `l2dll` to the `newNode` expression:\r\n{{{\r\nl2dll :: [a] -> IO (N a)\r\nl2dll (x:xs) = mdo c <- newNode l x f\r\n (f, l) <- l2dll' c xs\r\n return c\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2850GeneralizedNewtypeDeriving + TypeFamilies doesn't work2019-07-07T19:06:34ZajdGeneralizedNewtypeDeriving + TypeFamilies doesn't workIt would be nice if we could do stuff like this:
```
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-}
class K a where
bar :: a -> a
class K (B a) => M a where
data B a :: *
foo :: B a...It would be nice if we could do stuff like this:
```
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-}
class K a where
bar :: a -> a
class K (B a) => M a where
data B a :: *
foo :: B a -> B a
instance M Bool where
data B Bool = B1Bool Bool | B2Bool Bool
foo = id
instance K (B Bool) where
bar = id
instance M Int where
newtype B Int = BInt (B Bool) deriving K
foo = id
```
which currently gives the error
```
foo.hs:17:41:
Can't make a derived instance of `K (B Int)'
(even with cunning newtype deriving:
the newtype may be recursive)
In the newtype instance declaration for `B'
```
However, the newtype is not recursive, it is just an associated datatype from another class, so it seems like this ought to work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"GeneralizedNewtypeDeriving + TypeFamilies doesn't work","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be nice if we could do stuff like this:\r\n\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-}\r\nclass K a where\r\n bar :: a -> a\r\n\r\nclass K (B a) => M a where\r\n data B a :: *\r\n foo :: B a -> B a\r\n\r\ninstance M Bool where\r\n data B Bool = B1Bool Bool | B2Bool Bool\r\n foo = id\r\n\r\ninstance K (B Bool) where\r\n bar = id\r\n\r\ninstance M Int where\r\n newtype B Int = BInt (B Bool) deriving K\r\n foo = id\r\n}}}\r\n\r\nwhich currently gives the error\r\n\r\n{{{\r\nfoo.hs:17:41:\r\n Can't make a derived instance of `K (B Int)'\r\n (even with cunning newtype deriving:\r\n the newtype may be recursive)\r\n In the newtype instance declaration for `B'\r\n}}}\r\n\r\nHowever, the newtype is not recursive, it is just an associated datatype from another class, so it seems like this ought to work.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2860Redundant unblocking in POSIX generic_handler2019-07-07T19:06:31ZdshRedundant unblocking in POSIX generic_handlerGeneric handler redundantly unblocks signal at the end of generic handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.1...Generic handler redundantly unblocks signal at the end of generic handler.
<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 | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Redundant unblocking in POSIX generic_handler","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["POSIX","generic_handler"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Generic handler redundantly unblocks signal at the end of generic handler.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2861stage2 crash: PAP object entered!2019-07-07T19:06:31ZSimon Marlowstage2 crash: PAP object entered!With stage2 today:
```
$ ./ghc/stage2-inplace/ghc -package foo
ghc: internal error: PAP object entered!
(GHC version 6.11 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Int...With stage2 today:
```
$ ./ghc/stage2-inplace/ghc -package foo
ghc: internal error: PAP object entered!
(GHC version 6.11 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Interestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit...
```
a_r5fu :: GHC.Base.String
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.IOBase.IO [PackageConfig.PackageConfig]
[GlobalId]
[Arity 25]
a_r5fu =
\ (p_a1Pc :: GHC.Base.String)
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
(eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
(\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) ->
((Panic.ghcError
@ (GHC.IOBase.IO [PackageConfig.PackageConfig])
(Panic.CmdLineError
(Pretty.fullRender
@ GHC.Base.String
Pretty.PageMode
Pretty.lvl1
Pretty.lvl
Pretty.string_txt
(GHC.Types.[] @ GHC.Types.Char)
(Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc)))))
`cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]
:: GHC.IOBase.IO [PackageConfig.PackageConfig]
~
GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
[PackageConfig.PackageConfig] #)))
eta23_s5dN)
`cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig])
:: GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
[PackageConfig.PackageConfig] #)
~
GHC.IOBase.IO [PackageConfig.PackageConfig])
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"stage2 crash: PAP object entered!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With stage2 today:\r\n\r\n{{{\r\n$ ./ghc/stage2-inplace/ghc -package foo\r\nghc: internal error: PAP object entered!\r\n (GHC version 6.11 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nInterestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit...\r\n\r\n{{{\r\na_r5fu :: GHC.Base.String\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.IOBase.IO [PackageConfig.PackageConfig]\r\n[GlobalId]\r\n[Arity 25]\r\na_r5fu =\r\n \\ (p_a1Pc :: GHC.Base.String)\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n (eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n (\\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n ((Panic.ghcError\r\n @ (GHC.IOBase.IO [PackageConfig.PackageConfig])\r\n (Panic.CmdLineError\r\n (Pretty.fullRender\r\n @ GHC.Base.String\r\n Pretty.PageMode\r\n Pretty.lvl1\r\n Pretty.lvl\r\n Pretty.string_txt\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n (Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc)))))\r\n `cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]\r\n :: GHC.IOBase.IO [PackageConfig.PackageConfig]\r\n ~\r\n GHC.Prim.State# GHC.Prim.RealWorld\r\n -> (# GHC.Prim.State# GHC.Prim.RealWorld,\r\n [PackageConfig.PackageConfig] #)))\r\n eta23_s5dN)\r\n `cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig])\r\n :: GHC.Prim.State# GHC.Prim.RealWorld\r\n -> (# GHC.Prim.State# GHC.Prim.RealWorld,\r\n [PackageConfig.PackageConfig] #)\r\n ~\r\n GHC.IOBase.IO [PackageConfig.PackageConfig])\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2864ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug2019-07-07T19:06:30Zmegaczghc: panic! (the 'impossible' happened) -- Please report this as a GHC bugThe compiler asked me to report this.
```
/Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inative...The compiler asked me to report this.
```
/Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist-stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20081208 for i386-apple-darwin):
CoreToStg.myCollectArgs
(__scc {trivColorable ghc-6.11.20081208:MachRegs !}
ghc-6.11.20081208:MachRegs.isSqueesed{v r2zH} [gid] 0 0)
eta_s2Gv{v} [lid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 127672968 bytes, 16 GCs, 5231957/10604544 avg/max bytes residency (3 samples), 38M in use, 0.00 INIT (0.00 elapsed), 0.36 MUT (0.46 elapsed), 0.16 GC (0.19 elapsed) :ghc>>
make[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1
make[3]: *** [all] Error 1
make[2]: *** [build.stage.2] Error 2
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2
```
This is using git HEAD, commit 2aba6f168b7bcb4f8c7c8e8f7cdc340a0ccb56e76.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2868`par` `pseq` does not work as expected2019-07-07T19:06:29Zhoangta`par` `pseq` does not work as expectedThe following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile...The following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile and run by:
```
ghc --make -threaded wombat.hs
./wombat +RTS -N4
```
and the result is:
```
par sum: 119201850
par time: 20.932636 seconds.
seq sum: 119201850
seq time: 20.926783 seconds.
```
Please check if is is a bug.
```
---- wombat.hs ----
import System.Time
import Control.Parallel
fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
secDiff :: ClockTime -> ClockTime -> Float
secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) =
fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1)
mkList :: Int -> [Int]
mkList n = [1..n-1]
relprime :: Int -> Int -> Bool
relprime x y = gcd x y == 1
euler :: Int -> Int
euler n = length (filter (relprime n) (mkList n))
sumEuler :: Int -> Int
sumEuler = sum . (map euler) . mkList
seqSumFibEuler:: Int -> Int -> Int
seqSumFibEuler a b = fib a + sumEuler b
parSumFibEuler a b = f `par` (e `pseq` (e+ f))
where
f = fib a
e = sumEuler b
r1 = seqSumFibEuler 40 7450
r2 = parSumFibEuler 40 7450
main :: IO ()
main =
do
t0 <- getClockTime
pseq r1 (return())
t1 <- getClockTime
putStrLn ("seq sum: " ++ show r1)
putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " seconds.")
t0 <- getClockTime
pseq r2 (return())
t1 <- getClockTime
putStrLn ("par sum: " ++ show r2)
putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " seconds.")
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2881Basic Fibonacci function using Word causes ghci to panic. - 6.10.12019-07-07T19:06:26ZAlex MasonBasic Fibonacci function using Word causes ghci to panic. - 6.10.1When inputting the function:
```
let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)
```
GHCi produces a panic error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i3...When inputting the function:
```
let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)
```
GHCi produces a panic error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
schemeE(AnnCase).my_discr __word 0
```
It has been confirmed on both OS X 10.5.5 and linux
<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 | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Basif Fibonacci function using Word causes ghci to panic. - 6.10.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["Word","fibonacci","panic"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"When inputting the function:\r\n\r\n{{{\r\nlet fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)\r\n}}}\r\n\r\nGHCi produces a panic error:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tschemeE(AnnCase).my_discr __word 0\r\n}}}\r\n\r\nIt has been confirmed on both OS X 10.5.5 and linux\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2884Compiled code performance worsens when module names are long enough2019-07-07T19:06:25ZDaniel GorĂnCompiled code performance worsens when module names are long enoughAttached to this report is an example where by simply renaming a module, performance degrades 2.5 times.
```
#diff long-modname-ver.hs short-modname-ver.hs
2c2
< import VeryLongModuleName
---
> import ShortM
#diff VeryLongModuleName.hs...Attached to this report is an example where by simply renaming a module, performance degrades 2.5 times.
```
#diff long-modname-ver.hs short-modname-ver.hs
2c2
< import VeryLongModuleName
---
> import ShortM
#diff VeryLongModuleName.hs ShortM.hs
1c1
< module VeryLongModuleName
---
> module ShortM
#ghc --make -O2 -Wall long-modname-ver.hs
#ghc --make -O2 -Wall short-modname-ver.hs
#time -p ./long-modname-ver > /dev/null
real 55.90
user 55.17
sys 0.51
#time -p ./short-modname-ver > /dev/null
real 22.23
user 21.97
sys 0.10
```
According to some measures by dons, the threshold seems to be at module length 10 (see attached graph).
Some further disussion on this thread [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037](http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037).
<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":"Compiled code performance worsens when module names are long enough","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":"Attached to this report is an example where by simply renaming a module, performance degrades 2.5 times.\r\n\r\n{{{\r\n#diff long-modname-ver.hs short-modname-ver.hs\r\n2c2\r\n< import VeryLongModuleName\r\n---\r\n> import ShortM\r\n\r\n#diff VeryLongModuleName.hs ShortM.hs\r\n1c1\r\n< module VeryLongModuleName\r\n---\r\n> module ShortM\r\n\r\n#ghc --make -O2 -Wall long-modname-ver.hs\r\n\r\n#ghc --make -O2 -Wall short-modname-ver.hs\r\n\r\n#time -p ./long-modname-ver > /dev/null\r\nreal 55.90\r\nuser 55.17\r\nsys 0.51\r\n\r\n#time -p ./short-modname-ver > /dev/null\r\nreal 22.23\r\nuser 21.97\r\nsys 0.10\r\n}}}\r\n\r\nAccording to some measures by dons, the threshold seems to be at module length 10 (see attached graph).\r\n\r\nSome further disussion on this thread [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037].","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2906.hc code generated for Parser.hs is 2MB big2019-07-07T19:06:20Zbenl.hc code generated for Parser.hs is 2MB bigWhen compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file.
<details><summary>Trac...When compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file.
<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":".hc code generated for Parser.hs is 2MB big","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2951Add support for amd64-solaris2 platform2019-07-07T19:06:10ZkgardasAdd support for amd64-solaris2 platformHello,
it would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.\* string. Certainly there is a possibi...Hello,
it would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.\* string. Certainly there is a possibility to use `isainfo -n` to test for application supported instruction set, see:
```
karel@silence:~/vcs/ghc$ ./config.guess
i386-pc-solaris2.11
karel@silence:~/vcs/ghc$ isainfo -n
amd64
karel@silence:~/vcs/ghc$
```
I'm just not sure if hacking configure.ac's code below
```
i[[3456]]86-*-solaris2*)
HostPlatform=i386-unknown-solaris2 # hack again
TargetPlatform=i386-unknown-solaris2
BuildPlatform=i386-unknown-solaris2
HostPlatform_CPP='i386_unknown_solaris2'
HostArch_CPP='i386'
HostVendor_CPP='unknown'
HostOS_CPP='solaris2'
;;
```
and changing HostArch_CPP from 'i386' to 'x86_64' would be enough for the change.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Add support for amd64-solaris2 platform","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Hello,\r\n\r\nit would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.* string. Certainly there is a possibility to use `isainfo -n` to test for application supported instruction set, see:\r\n{{{\r\nkarel@silence:~/vcs/ghc$ ./config.guess \r\ni386-pc-solaris2.11\r\nkarel@silence:~/vcs/ghc$ isainfo -n\r\namd64\r\nkarel@silence:~/vcs/ghc$ \r\n}}}\r\n\r\nI'm just not sure if hacking configure.ac's code below\r\n{{{\r\ni[[3456]]86-*-solaris2*)\r\n HostPlatform=i386-unknown-solaris2 # hack again\r\n TargetPlatform=i386-unknown-solaris2\r\n BuildPlatform=i386-unknown-solaris2\r\n HostPlatform_CPP='i386_unknown_solaris2'\r\n HostArch_CPP='i386'\r\n HostVendor_CPP='unknown'\r\n HostOS_CPP='solaris2'\r\n ;;\r\n}}}\r\nand changing HostArch_CPP from 'i386' to 'x86_64' would be enough for the change.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2962Reduce space usage of genericLength for common Num instances2019-07-07T19:06:07ZthorkilnaurReduce space usage of genericLength for common Num instancesThere is a space leak in `genericLength`:
```
$ ghc/stage2-inplace/ghc --interactive
GHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linkin...There is a space leak in `genericLength`:
```
$ ghc/stage2-inplace/ghc --interactive
GHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :module +List
Prelude List> genericLength [1..600000]
*** Exception: stack overflow
Prelude List>
Prelude List> length [1..600000]
600000
Prelude List>
```
The attached patch against the base library provides a fix.
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix space leak in genericLength","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a space leak in {{{genericLength}}}:\r\n{{{\r\n$ ghc/stage2-inplace/ghc --interactive\r\nGHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> :module +List\r\nPrelude List> genericLength [1..600000]\r\n*** Exception: stack overflow\r\nPrelude List>\r\nPrelude List> length [1..600000]\r\n600000\r\nPrelude List>\r\n}}}\r\nThe attached patch against the base library provides a fix.\r\n\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchthorkilnaurthorkilnaurhttps://gitlab.haskell.org/ghc/ghc/-/issues/2981".space" directive not recognised by solaris assembler2019-07-07T19:06:01Zduncan".space" directive not recognised by solaris assemblerThe Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.
```
/usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space"
/usr/ccs/bin/as: "test.s", line 484: error: ...The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.
```
/usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space"
/usr/ccs/bin/as: "test.s", line 484: error: statement syntax
```
It happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code:
`compiler/nativeGen/PprMach.hs:`
```
pprData (CmmUninitialised bytes) = ptext (sLit ".space ") <> int bytes
```
does not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\".space\" directive not recognised by solaris assembler","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.\r\n\r\n{{{\r\n/usr/ccs/bin/as: \"test.s\", line 484: error: unknown opcode \".space\"\r\n/usr/ccs/bin/as: \"test.s\", line 484: error: statement syntax\r\n}}}\r\n\r\nIt happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code:\r\n\r\n`compiler/nativeGen/PprMach.hs:`\r\n{{{\r\npprData (CmmUninitialised bytes) = ptext (sLit \".space \") <> int bytes\r\n}}}\r\n\r\ndoes not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/2984Vectorized dph code doesn't terminate2019-07-07T19:06:00ZfreVectorized dph code doesn't terminateThe program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.
The problem seems to be the use of sumP or mapP with the empty array.
<details><summary>Trac metadata</su...The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.
The problem seems to be the use of sumP or mapP with the empty array.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Vectorized dph code doesn't terminate","status":"New","operating_system":"Linux","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.\r\n\r\nThe problem seems to be the use of sumP or mapP with the empty array. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchrl@cse.unsw.edu.aurl@cse.unsw.edu.au