GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:03:12Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3595The forefathers of Haskell ...2019-07-07T19:03:12ZJohnDThe forefathers of Haskell ...17 October 2009
I am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes a...17 October 2009
I am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes any sense with those who are better acquainted with Haskell and more specifically GHC, and are closer to the problem.
Haskell is an expressive language. GHC is needed to build GHC as it is. Why not create a build system that does not rely on shell scripts and make files? We would have all the benefits of a type safe language, type inference and the like. It seems to me that the build system is a weak link. Since when is the software developer's time unimportant? Strike that, it makes me sound like I was born yesterday. :-)
At one time the lack of a type system would have been regarded as an asset, less bureaucracy. Haskell has type inference. It wouldn't be a burden, it would be an asset. You get to find out if the build system is broken without having to learn the hard way and having wasted hours or days of your precious time on something that is silly. GHC produces better error messages and is better at catching mistakes. It furthermore has an interpreter. From a theoretical point of view that's everything. What came first the chicken or the egg? What came first was the interpreter, then came the chicken. So technically it isn't an interpreter--it's a translator! He he.
Unix/GNU is a mature product. It's ancient as in stone age, but mature. Some things might be missed. I recently installed Windows Vista on my computer. As usual there is what they got wrong, but also all the things they got right. It will take time to get used to it. So I suppose I can relate to those who might oppose change. I made a investment becoming familiar with Windows XP. It was comfortable. Equally many of you are vested in the old way of doing things. It has been around for so long that no one questions it.
What exactly is unique about make files that you can't do in any other language? Well, the syntax lends itself to the task. Why couldn't Prolog be used? With Prolog you don't always have an interactive environment. The forefathers of Haskell weren't short sited and understood the value of having both a compiler and interactive environment. Is it merely convenience and something that aids in debugging? or is there more to it? There is the Curry language which is based on Haskell and it is my understanding that some of the features of the Curry language are now GHC extensions. Make files are a poor man's Prolog whereas Prolog is the tool of aristocrats.
If you take an objective look at the stone age tools, you will see something grotesque. It has to be survival of the fittest. It just isn't fit. It shouldn't survive. It would be wrong for it to survive. All that Haskell represents is what needs to survive.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"The forefathers of Haskell ...","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"17 October 2009\r\n\r\nI am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes any sense with those who are better acquainted with Haskell and more specifically GHC, and are closer to the problem.\r\n\r\nHaskell is an expressive language. GHC is needed to build GHC as it is. Why not create a build system that does not rely on shell scripts and make files? We would have all the benefits of a type safe language, type inference and the like. It seems to me that the build system is a weak link. Since when is the software developer's time unimportant? Strike that, it makes me sound like I was born yesterday. :-)\r\n\r\nAt one time the lack of a type system would have been regarded as an asset, less bureaucracy. Haskell has type inference. It wouldn't be a burden, it would be an asset. You get to find out if the build system is broken without having to learn the hard way and having wasted hours or days of your precious time on something that is silly. GHC produces better error messages and is better at catching mistakes. It furthermore has an interpreter. From a theoretical point of view that's everything. What came first the chicken or the egg? What came first was the interpreter, then came the chicken. So technically it isn't an interpreter--it's a translator! He he.\r\n\r\nUnix/GNU is a mature product. It's ancient as in stone age, but mature. Some things might be missed. I recently installed Windows Vista on my computer. As usual there is what they got wrong, but also all the things they got right. It will take time to get used to it. So I suppose I can relate to those who might oppose change. I made a investment becoming familiar with Windows XP. It was comfortable. Equally many of you are vested in the old way of doing things. It has been around for so long that no one questions it.\r\n\r\nWhat exactly is unique about make files that you can't do in any other language? Well, the syntax lends itself to the task. Why couldn't Prolog be used? With Prolog you don't always have an interactive environment. The forefathers of Haskell weren't short sited and understood the value of having both a compiler and interactive environment. Is it merely convenience and something that aids in debugging? or is there more to it? There is the Curry language which is based on Haskell and it is my understanding that some of the features of the Curry language are now GHC extensions. Make files are a poor man's Prolog whereas Prolog is the tool of aristocrats.\r\n\r\nIf you take an objective look at the stone age tools, you will see something grotesque. It has to be survival of the fittest. It just isn't fit. It shouldn't survive. It would be wrong for it to survive. All that Haskell represents is what needs to survive.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3594ppc stage1 panic for --enable-shared2019-07-07T19:03:12ZJens Petersenppc stage1 panic for --enable-sharedNot sure if this is expected but ghc-6.12 panics on ppc
when it starts to build shared libraries:
```
/usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaskeline-0.6.2.1.a
"inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -...Not sure if this is expected but ghc-6.12 panics on ppc
when it starts to build shared libraries:
```
/usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaskeline-0.6.2.1.a
"inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.12.0.20091010 for powerpc-unknown-linux):
getRegisterReg-memory PicBaseReg
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o] Error 1
make: *** [all] Error 2
```
so reporting it here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ppc stage1 panic for --enable-shared","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Not sure if this is expected but ghc-6.12 panics on ppc\r\nwhen it starts to build shared libraries:\r\n\r\n{{{\r\n/usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaskeline-0.6.2.1.a\r\n\"inplace/bin/ghc-stage1\" -fPIC -dynamic -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 6.12.0.20091010 for powerpc-unknown-linux):\r\n getRegisterReg-memory PicBaseReg\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nmake[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o] Error 1\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\nso reporting it here.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3593Where has readline gone?2019-07-07T19:03:12ZspiveyWhere has readline gone?In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I ...In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Where has readline gone?","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3592Eta-contraction gives a rather bogus type error message2019-07-07T19:03:12ZguestEta-contraction gives a rather bogus type error messageConsider the following program:
```
module Main where
type T a = Show a => a
f :: T a -> String
f = show
```
Compiling this with GHC 6.10.3 and -fglasgow-exts gives:
```
[1 of 1] Compiling Main ( Test.hs, interpreted )
g...Consider the following program:
```
module Main where
type T a = Show a => a
f :: T a -> String
f = show
```
Compiling this with GHC 6.10.3 and -fglasgow-exts gives:
```
[1 of 1] Compiling Main ( Test.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
TcTyFuns.flattenType: unexpected PredType
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thomas@cs.ru.nl |
| Operating system | MacOS X |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic! on overloaded type synonym","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":["thomas@cs.ru.nl"],"type":"Bug","description":"Consider the following program:\r\n\r\n{{{\r\nmodule Main where\r\n\r\ntype T a = Show a => a\r\n\r\nf :: T a -> String\r\nf = show\r\n}}}\r\n\r\nCompiling this with GHC 6.10.3 and -fglasgow-exts gives:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( Test.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-apple-darwin):\r\n\tTcTyFuns.flattenType: unexpected PredType\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3591A working program reports <<loop>> when compiled with -O2021-04-07T16:37:52ZGhost UserA working program reports <<loop>> when compiled with -OIf the attached module Trampoline.hs is compiled with no optimizations it works:
```
$ ghc --make Trampoline.hs
[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )
Linking Trampoline ...
$ ./Trampoline
...
((5,2),(1,...If the attached module Trampoline.hs is compiled with no optimizations it works:
```
$ ghc --make Trampoline.hs
[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )
Linking Trampoline ...
$ ./Trampoline
...
((5,2),(1,2,6))
$
```
With optimizations on, it hangs:
```
$ ghc --make Trampoline.hs -O
[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )
Linking Trampoline ...
$ ./Trampoline
bounce start
bounce end
liftOut
inject suspend
Trampoline: <<loop>>
```
That doesn't seem right. Oh, GHCi runs it with no problem as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"A working program reports <<loop>> when compiled with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If the attached module Trampoline.hs is compiled with no optimizations it works:\r\n\r\n{{{\r\n$ ghc --make Trampoline.hs \r\n[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )\r\nLinking Trampoline ...\r\n$ ./Trampoline \r\n...\r\n((5,2),(1,2,6))\r\n$ \r\n}}}\r\n\r\nWith optimizations on, it hangs:\r\n\r\n{{{\r\n$ ghc --make Trampoline.hs -O\r\n[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )\r\nLinking Trampoline ...\r\n$ ./Trampoline \r\nbounce start\r\nbounce end\r\nliftOut\r\ninject suspend\r\nTrampoline: <<loop>>\r\n}}}\r\n\r\nThat doesn't seem right. Oh, GHCi runs it with no problem as well.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3590panic (the impossible happened) when compiling with -O22019-07-07T19:03:13Zyairchupanic (the impossible happened) when compiling with -O2when compiling the attached program with -O2 I get the following error:
```
[1 of 1] Compiling Main ( crashTest.hs, crashTest.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-apple-darwin):
Coercio...when compiling the attached program with -O2 I get the following error:
```
[1 of 1] Compiling Main ( crashTest.hs, crashTest.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-apple-darwin):
Coercion.splitCoercionKindOf
ghc-prim:GHC.Prim.left{(w) tc 34B}
(ghc-prim:GHC.Prim.trans{(w) tc 34y}
(List-0.3:Data.List.Class.ItemM{tc r28}
(List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))
(List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]) c{tv ayR} [sk]))
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]
List-0.3:Control.Monad.ListT.:CoF:R5ItemM{tc r29} List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D}
a{tv ayS} [sk])
c{tv ayR} [sk]))
<pred>List-0.3:Data.List.Class.ItemM{tc r28}
(List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))
~
ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
When compiling without -O2, it works.
I am using TypeFamilies (for the List class)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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 (the impossible happened) when compiling with -O2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"when compiling the attached program with -O2 I get the following error:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( crashTest.hs, crashTest.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-apple-darwin):\r\n\tCoercion.splitCoercionKindOf\r\n ghc-prim:GHC.Prim.left{(w) tc 34B}\r\n (ghc-prim:GHC.Prim.trans{(w) tc 34y}\r\n (List-0.3:Data.List.Class.ItemM{tc r28}\r\n (List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))\r\n (List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]) c{tv ayR} [sk]))\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]\r\n List-0.3:Control.Monad.ListT.:CoF:R5ItemM{tc r29} List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D}\r\n a{tv ayS} [sk])\r\n c{tv ayR} [sk]))\r\n <pred>List-0.3:Data.List.Class.ItemM{tc r28}\r\n (List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))\r\n ~\r\n ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nWhen compiling without -O2, it works.\r\nI am using TypeFamilies (for the List class)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3589Recompilation checker doesn't take into account CPP headers2019-07-07T19:03:13ZSimon MarlowRecompilation checker doesn't take into account CPP headersWhen using CPP, the recompilation checker doesn't check the date on any header files that might be `#included`. We already have to run CPP on the file anyway in order to extract the imports and module name, so we might as find the `#incl...When using CPP, the recompilation checker doesn't check the date on any header files that might be `#included`. We already have to run CPP on the file anyway in order to extract the imports and module name, so we might as find the `#included` files and check their modification times.
See also #3588.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Recompilation checker doesn't take into account CPP headers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.14 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using CPP, the recompilation checker doesn't check the date on any header files that might be `#included`. We already have to run CPP on the file anyway in order to extract the imports and module name, so we might as find the `#included` files and check their modification times.\r\n\r\nSee also #3588.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/3588ghc -M should emit dependencies on CPP headers2019-07-07T19:03:14ZSimon Marlowghc -M should emit dependencies on CPP headersWhen using CPP, ghc -M should emit dependencies on header files that are `#included` into Haskell source code. It could do this by running `gcc -M`, perhaps.
<details><summary>Trac metadata</summary>
| Trac field | Value ...When using CPP, ghc -M should emit dependencies on header files that are `#included` into Haskell source code. It could do this by running `gcc -M`, perhaps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc -M should emit dependencies on CPP headers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.14 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using CPP, ghc -M should emit dependencies on header files that are `#included` into Haskell source code. It could do this by running `gcc -M`, perhaps.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3587provide a cross-platform way to set environment variables2019-07-07T19:03:14Zshahnprovide a cross-platform way to set environment variablesSystem.Environment contains cross-platform operations to query environment variables, not to modify them. System.Posix.Env (package unix) provides operations to set environment variables on Linux (and probably other unices). This ticket ...System.Environment contains cross-platform operations to query environment variables, not to modify them. System.Posix.Env (package unix) provides operations to set environment variables on Linux (and probably other unices). This ticket requests adding cross-platform operations to set env vars to the module System.Environment.
As a workaround i copied the implementation of [System.Posix.Env.putEnv](http://hackage.haskell.org/packages/archive/unix/2.3.2.0/doc/html/src/System-Posix-Env.html#putEnv) into a new module. That seems to work on windows and linux (for me. Maybe this is due to using mingw/msys, though).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"provide a cross-platform way to set environment variables","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["environment","variable"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"System.Environment contains cross-platform operations to query environment variables, not to modify them. System.Posix.Env (package unix) provides operations to set environment variables on Linux (and probably other unices). This ticket requests adding cross-platform operations to set env vars to the module System.Environment.\r\n\r\nAs a workaround i copied the implementation of [http://hackage.haskell.org/packages/archive/unix/2.3.2.0/doc/html/src/System-Posix-Env.html#putEnv System.Posix.Env.putEnv] into a new module. That seems to work on windows and linux (for me. Maybe this is due to using mingw/msys, though).\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3586Initialisation of unboxed arrays is too slow2022-03-16T08:32:45ZSimon Peyton JonesInitialisation of unboxed arrays is too slowOn the Clean mailing list, Philippos Apolinarius \[phi500ac\@yahoo.ca\] describes a small array program (using the ST monad) that runs 400x more slowly in Haskell than Clean. I can understand a bit slower (e.g. maybe they do a better job...On the Clean mailing list, Philippos Apolinarius \[phi500ac\@yahoo.ca\] describes a small array program (using the ST monad) that runs 400x more slowly in Haskell than Clean. I can understand a bit slower (e.g. maybe they do a better job of array-bound checks), but 400x seems large. This ticket is an invitation for someone to investigate.
He writes: I wrote a very simple program to check whether Haskell improved its array processing libraries or not. Here is how to compile and run the program arr.hs in Haskell (I have used the GHC compiler):
```
>ghc -O arr.hs -o arr.exe
$ time arr.exe +RTS -K32000000
2.8e8
real 0m3.938s
user 0m0.031s
sys 0m0.000s
```
The same program in Clean:
```
C:\Clean 2.2\exemplos\console>arraytest.exe
280000000
Execution: 0.01 Garbage collection: 0.01 Total: 0.03
C:\Clean 2.2\exemplos\console>arraytest.exe
280000000
Execution: 0.01 Garbage collection: 0.01 Total: 0.03
```
This means that Clean is 390 times faster than Haskell in this particular problem. These results makes me worder whether Haskell is safer than Clean. It turns out that Haskell checks index out of range at runtime, exactly like Clean. Larger problems make the difference between Clean and Haskell even worse. For instance, neural networks like the one described in Schmidtt et al. run 400 times faster in Clean.
Below you will find the array examples. You can check that Clean is really much faster than Haskell. I wonder why the Benchmarks Game site does not report such a large difference between Haskell and Clean performances. I believe that people who wrote Haskell benchmarks for the Benchmarks Game site cheated in using foreign pointers to access arrays.
```
-- arr.hs
import Control.Monad.ST
import Data.Array.ST
main = print $ runST
(do arr <- newArray (1,2000000)
137.0 :: ST s
(STArray s
Int Double)
a <- readArray arr 1
b <- readArray arr 1
fn 2000000 arr 0.0 )
fn i a acc | i < 1 = do (return acc)
fn i a acc= do
b <- readArray a i
writeArray a i (b+3.0)
c <- readArray a i
fn (i-1) a (acc+c)
```
Clean version
```
module arraytest
import StdEnv
fn i a acc | i<1 = acc
fn i a=:{[i]=b} acc
# a= {a&[i]= b+3.0}
# (c, a)= a![i]
= fn (i-1) a (c+acc)
Start= fn 2000000 vt 0.0
where
vt:: .{#Real}
vt = createArray 2000001 137.0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Slow array code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On the Clean mailing list, Philippos Apolinarius [phi500ac@yahoo.ca] describes a small array program (using the ST monad) that runs 400x more slowly in Haskell than Clean. I can understand a bit slower (e.g. maybe they do a better job of array-bound checks), but 400x seems large. This ticket is an invitation for someone to investigate.\r\n\r\nHe writes: I wrote a very simple program to check whether Haskell improved its array processing libraries or not. Here is how to compile and run the program arr.hs in Haskell (I have used the GHC compiler):\r\n{{{\r\n>ghc -O arr.hs -o arr.exe\r\n\r\n$ time arr.exe +RTS -K32000000\r\n2.8e8\r\n\r\nreal 0m3.938s\r\nuser 0m0.031s\r\nsys 0m0.000s\r\n}}}\r\nThe same program in Clean:\r\n{{{\r\nC:\\Clean 2.2\\exemplos\\console>arraytest.exe\r\n280000000\r\nExecution: 0.01 Garbage collection: 0.01 Total: 0.03\r\n\r\nC:\\Clean 2.2\\exemplos\\console>arraytest.exe\r\n280000000\r\nExecution: 0.01 Garbage collection: 0.01 Total: 0.03\r\n}}}\r\nThis means that Clean is 390 times faster than Haskell in this particular problem. These results makes me worder whether Haskell is safer than Clean. It turns out that Haskell checks index out of range at runtime, exactly like Clean. Larger problems make the difference between Clean and Haskell even worse. For instance, neural networks like the one described in Schmidtt et al. run 400 times faster in Clean.\r\n\r\nBelow you will find the array examples. You can check that Clean is really much faster than Haskell. I wonder why the Benchmarks Game site does not report such a large difference between Haskell and Clean performances. I believe that people who wrote Haskell benchmarks for the Benchmarks Game site cheated in using foreign pointers to access arrays.\r\n{{{\r\n-- arr.hs\r\nimport Control.Monad.ST\r\nimport Data.Array.ST\r\nmain = print $ runST\r\n (do arr <- newArray (1,2000000) \r\n 137.0 :: ST s \r\n (STArray s \r\n Int Double)\r\n a <- readArray arr 1\r\n b <- readArray arr 1\r\n fn 2000000 arr 0.0 )\r\n\r\n\r\nfn i a acc | i < 1 = do (return acc) \r\nfn i a acc= do \r\n b <- readArray a i\r\n writeArray a i (b+3.0)\r\n c <- readArray a i\r\n fn (i-1) a (acc+c)\r\n}}}\r\nClean version\r\n{{{\r\nmodule arraytest\r\nimport StdEnv\r\nfn i a acc | i<1 = acc\r\nfn i a=:{[i]=b} acc\r\n # a= {a&[i]= b+3.0}\r\n # (c, a)= a![i]\r\n = fn (i-1) a (c+acc)\r\n \r\nStart= fn 2000000 vt 0.0\r\nwhere\r\n vt:: .{#Real}\r\n vt = createArray 2000001 137.0\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3585runhaskell displays an UTF-8 decoding error2019-07-07T19:03:15ZManuel M T Chakravartyrunhaskell displays an UTF-8 decoding errorI have the following problem with the 6.12.1RC1 Mac installer package on Snow Leopard:
```
WithinReason chak 9 (.../Code/haskell): file HelloWorld.hs
HelloWorld.hs: ASCII text
WithinReason chak 10 (.../Code/haskell): cat HelloWorld.hs
m...I have the following problem with the 6.12.1RC1 Mac installer package on Snow Leopard:
```
WithinReason chak 9 (.../Code/haskell): file HelloWorld.hs
HelloWorld.hs: ASCII text
WithinReason chak 10 (.../Code/haskell): cat HelloWorld.hs
main = putStrLn "Hello World!"
WithinReason chak 11 (.../Code/haskell): runhaskell HelloWorld
HelloWorld:1:0: lexical error (UTF-8 decoding error)
WithinReason chak 12 (.../Code/haskell):
```
I reckon that this is not Snow Leopard-specific, but I didn't verify that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| 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":"runhaskell displays an UTF-8 decoding error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have the following problem with the 6.12.1RC1 Mac installer package on Snow Leopard:\r\n{{{\r\nWithinReason chak 9 (.../Code/haskell): file HelloWorld.hs\r\nHelloWorld.hs: ASCII text\r\nWithinReason chak 10 (.../Code/haskell): cat HelloWorld.hs\r\nmain = putStrLn \"Hello World!\"\r\nWithinReason chak 11 (.../Code/haskell): runhaskell HelloWorld\r\n\r\nHelloWorld:1:0: lexical error (UTF-8 decoding error)\r\nWithinReason chak 12 (.../Code/haskell):\r\n}}}\r\n\r\nI reckon that this is not Snow Leopard-specific, but I didn't verify that.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3584type signature involving a type family rejected2019-07-07T19:03:15Zbaramoglotype signature involving a type family rejected`add1` is rejected in the following program:
```
{-# LANGUAGE EmptyDataDecls, FlexibleContexts, FlexibleInstances, GADTs, TypeFamilies, TypeOperators, UndecidableInstances #-}
data False
type family IsNegative x
type family x :+: y
...`add1` is rejected in the following program:
```
{-# LANGUAGE EmptyDataDecls, FlexibleContexts, FlexibleInstances, GADTs, TypeFamilies, TypeOperators, UndecidableInstances #-}
data False
type family IsNegative x
type family x :+: y
class Natural x
instance (IsNegative x ~ False) => Natural x
data A n
where
A :: Natural n => Int -> A n
getA :: A n -> Int
getA (A n) = n
add1 :: Natural (m:+:n) => A m -> A n -> A (m:+:n)
add1 (A a) (A b) = A (a+b)
add2 (A a) (A b) = A (a+b)
add3 :: (IsNegative (m:+:n) ~ False) => A m -> A n -> A (m:+:n)
add3 (A a) (A b) = A (a+b)
add4 :: Natural (m:+:n) => A m -> A n -> A (m:+:n)
add4 a b = A (getA a + getA b)
add5 :: Natural (m:+:n) => A m -> A n -> A (m:+:n)
add5 (A a) _ = A a
```
The following modifications of `add1` work fine:
- Removing the type signature (`add2`)
- Using the type inferred for `add2` (`add3`)
- Using the projection function `getA` instead of pattern matching (`add4`)
- Only pattern match on the first argument
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | 78emil@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"type signature involving a type family rejected","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["78emil@gmail.com"],"type":"Bug","description":"`add1` is rejected in the following program:\r\n{{{\r\n{-# LANGUAGE EmptyDataDecls, FlexibleContexts, FlexibleInstances, GADTs, TypeFamilies, TypeOperators, UndecidableInstances #-}\r\n\r\ndata False\r\n\r\ntype family IsNegative x\r\n\r\ntype family x :+: y\r\n\r\nclass Natural x\r\ninstance (IsNegative x ~ False) => Natural x\r\n\r\ndata A n\r\n where\r\n A :: Natural n => Int -> A n\r\n\r\ngetA :: A n -> Int\r\ngetA (A n) = n\r\n\r\nadd1 :: Natural (m:+:n) => A m -> A n -> A (m:+:n)\r\nadd1 (A a) (A b) = A (a+b)\r\n\r\nadd2 (A a) (A b) = A (a+b)\r\n\r\nadd3 :: (IsNegative (m:+:n) ~ False) => A m -> A n -> A (m:+:n)\r\nadd3 (A a) (A b) = A (a+b)\r\n\r\nadd4 :: Natural (m:+:n) => A m -> A n -> A (m:+:n)\r\nadd4 a b = A (getA a + getA b)\r\n\r\nadd5 :: Natural (m:+:n) => A m -> A n -> A (m:+:n)\r\nadd5 (A a) _ = A a\r\n}}}\r\nThe following modifications of `add1` work fine:\r\n\r\n * Removing the type signature (`add2`)\r\n * Using the type inferred for `add2` (`add3`)\r\n * Using the projection function `getA` instead of pattern matching (`add4`)\r\n * Only pattern match on the first argument","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3583Default view patterns2019-07-07T19:03:16ZksfDefault view patternsas useful for code like http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699\#a10699 : Provide a unified left-hand interface for \[\] and Seq with the same syntax as current lists.
<details><summary>Trac metadata</summary>
| Trac field ...as useful for code like http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699\#a10699 : Provide a unified left-hand interface for \[\] and Seq with the same syntax as current lists.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| 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":"Default view patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"as useful for code like http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699#a10699 : Provide a unified left-hand interface for [] and Seq with the same syntax as current lists.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3582Compiling with optimizations on hurts performance2019-07-07T19:03:16ZgchrupalaCompiling with optimizations on hurts performanceThe attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine).
I wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to proces...The attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine).
I wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to process).
I compiled and ran like this:
> ghc --make test2.hs
> time ./test2
And then
> ghc --make test2 -fforce-recomp -O
> time ./test2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Compiling with optimizations on hurts performance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["optimization"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine).\r\n\r\nI wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to process).\r\n\r\nI compiled and ran like this:\r\n> ghc --make test2.hs\r\n> time ./test2\r\nAnd then \r\n> ghc --make test2 -fforce-recomp -O\r\n> time ./test2\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3581Compiling with optimizations on hurts performance2019-07-07T19:03:16ZgchrupalaCompiling with optimizations on hurts performanceThe attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine).
I wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to proces...The attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine).
I wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to process).
I compiled and ran like this:
> ghc --make test2.hs
> time ./test2
And then
> ghc --make test2 -fforce-recomp -O
> time ./test2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Compiling with optimizations on hurts performance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["optimization"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine).\r\n\r\nI wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to process).\r\n\r\nI compiled and ran like this:\r\n> ghc --make test2.hs\r\n> time ./test2\r\nAnd then \r\n> ghc --make test2 -fforce-recomp -O\r\n> time ./test2\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3580ghc-6.12.1rc1 on Nix: ghci does not work2019-07-07T19:03:16ZAndres Löhghc-6.12.1rc1 on Nix: ghci does not workAfter building the ghc-6.12.1 release candidate on a 32-bit Arch Linux machine
using Nix, ghci fails to start with the following error:
```
GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim...After building the ghc-6.12.1 release candidate on a 32-bit Arch Linux machine
using Nix, ghci fails to start with the following error:
```
GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
ghc-stage2: /nix/store/nkg79yilgrdcfpkrfvr15jrg2v49svrn-ghc-6.12.0.20091010/lib/ghc-6.12.0.20091010/HSffi.o: no string tables, or too many
Loading package ffi-1.0 ... ghc-stage2: panic! (the 'impossible' happened)
(GHC version 6.12.0.20091010 for i386-unknown-linux):
loadObj: failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I know that I encountered this problem before when trying to build the HEAD a couple
of months before, but I didn't ever have this problem with ghc-6.10.\* using Nix.
Any ideas?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-6.12.1rc1 on Nix: ghci does not work","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After building the ghc-6.12.1 release candidate on a 32-bit Arch Linux machine\r\nusing Nix, ghci fails to start with the following error:\r\n{{{\r\nGHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nghc-stage2: /nix/store/nkg79yilgrdcfpkrfvr15jrg2v49svrn-ghc-6.12.0.20091010/lib/ghc-6.12.0.20091010/HSffi.o: no string tables, or too many\r\nLoading package ffi-1.0 ... ghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 6.12.0.20091010 for i386-unknown-linux):\r\n\tloadObj: failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI know that I encountered this problem before when trying to build the HEAD a couple\r\nof months before, but I didn't ever have this problem with ghc-6.10.* using Nix.\r\n\r\nAny ideas?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3579Error: symbol `Bug_compose1_closure' is already defined2019-07-07T19:03:16ZIan Lynagh <igloo@earth.li>Error: symbol `Bug_compose1_closure' is already definedIn http://www.haskell.org/pipermail/glasgow-haskell-bugs/2009-October/020608.html Serge reports:
```
module Bug where
compose :: [a -> a] -> a -> a
compose = foldr (.) id
class Compose a where
compose1 :: a -> a -> a
```
```
$ g...In http://www.haskell.org/pipermail/glasgow-haskell-bugs/2009-October/020608.html Serge reports:
```
module Bug where
compose :: [a -> a] -> a -> a
compose = foldr (.) id
class Compose a where
compose1 :: a -> a -> a
```
```
$ ghc -c -O p.hs
/tmp/ghc12944_0/ghc12944_0.s: Assembler messages:
/tmp/ghc12944_0/ghc12944_0.s:22:0:
Error: symbol `Bug_compose1_closure' is already defined
/tmp/ghc12944_0/ghc12944_0.s:98:0:
Error: symbol `Bug_compose1_info' is already defined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"Error: symbol `Bug_compose1_closure' is already defined","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In http://www.haskell.org/pipermail/glasgow-haskell-bugs/2009-October/020608.html Serge reports:\r\n\r\n{{{\r\nmodule Bug where\r\n\r\ncompose :: [a -> a] -> a -> a\r\ncompose = foldr (.) id\r\n\r\nclass Compose a where\r\n compose1 :: a -> a -> a\r\n}}}\r\n\r\n{{{\r\n$ ghc -c -O p.hs\r\n/tmp/ghc12944_0/ghc12944_0.s: Assembler messages:\r\n\r\n/tmp/ghc12944_0/ghc12944_0.s:22:0:\r\n Error: symbol `Bug_compose1_closure' is already defined\r\n\r\n/tmp/ghc12944_0/ghc12944_0.s:98:0:\r\n Error: symbol `Bug_compose1_info' is already defined\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3578internal error: evacuate(static): strange closure type 422019-07-07T19:03:17Znccbinternal error: evacuate(static): strange closure type 42I have a concurrent program (using CHP, which sits on top of STM+forkIO), that is able to produce this error on GHC 6.12.1-rc1 (which doesn't appear on your version drop-down):
chp-boids: internal error: evacuate(static): strange closur...I have a concurrent program (using CHP, which sits on top of STM+forkIO), that is able to produce this error on GHC 6.12.1-rc1 (which doesn't appear on your version drop-down):
chp-boids: internal error: evacuate(static): strange closure type 42
(GHC version 6.12.0.20091010 for i386_unknown_linux)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
It produces it much sooner with +RTS -N2 than +RTS -N1, but both settings can produce the error. The output doesn't look like it will be very useful to you -- what can I run to give a better output?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.13 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error: evacuate(static): strange closure type 42","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a concurrent program (using CHP, which sits on top of STM+forkIO), that is able to produce this error on GHC 6.12.1-rc1 (which doesn't appear on your version drop-down):\r\n\r\nchp-boids: internal error: evacuate(static): strange closure type 42\r\n (GHC version 6.12.0.20091010 for i386_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n\r\nIt produces it much sooner with +RTS -N2 than +RTS -N1, but both settings can produce the error. The output doesn't look like it will be very useful to you -- what can I run to give a better output?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3577Complete support for Data Parallel Haskell2023-12-01T14:04:11Zrl@cse.unsw.edu.auComplete support for Data Parallel HaskellI'm going to open this as a placeholder for all the things the vectoriser can't do yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| V...I'm going to open this as a placeholder for all the things the vectoriser can't do yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.13 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Complete support for Data Parallel Haskell","status":"New","operating_system":"","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"rl"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm going to open this as a placeholder for all the things the vectoriser can't do yet.","type_of_failure":"OtherFailure","blocking":[]} -->rl@cse.unsw.edu.aurl@cse.unsw.edu.auhttps://gitlab.haskell.org/ghc/ghc/-/issues/3576minor errors in docs/users_guide/6.12.1-notes.xml2019-07-07T19:03:17Zrwbartonminor errors in docs/users_guide/6.12.1-notes.xml- `listitem` is misspelled a total of 4 times as `listierm` (two open tags, two close tags).
- The `-fwarn-unused-do-bind` flag is documented in two items. Probably the second item should be removed. It would be nice to include a link to...- `listitem` is misspelled a total of 4 times as `listierm` (two open tags, two close tags).
- The `-fwarn-unused-do-bind` flag is documented in two items. Probably the second item should be removed. It would be nice to include a link to the relevant part of Section 4.7 in the first item.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"minor errors in docs/users_guide/6.12.1-notes.xml","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":" * `listitem` is misspelled a total of 4 times as `listierm` (two open tags, two close tags).\r\n\r\n * The `-fwarn-unused-do-bind` flag is documented in two items. Probably the second item should be removed. It would be nice to include a link to the relevant part of Section 4.7 in the first item.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlow