GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:59:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4237-dcore-lint error after simplifier iteration 1 when profiling2019-07-07T18:59:55ZWolfram Kahl-dcore-lint error after simplifier iteration 1 when profilingThis happens with the current development version of Agda, with last change from July 20.
```
darcs get --lazy http://code.haskell.org/Agda
```
I did:
```
./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcor...This happens with the current development version of Agda, with last change from July 20.
```
darcs get --lazy http://code.haskell.org/Agda
```
I did:
```
./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcore-lint
./Setup build -v > build.log 2>&1
```
`build.log` is attached, and shows a core-lint error in the profiling way.
I tried this since I am getting segfaults and other errors in long Agda runs with more than 4GB heap, and have no idea yet how to trim them down.
Wolfram
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"-dcore-lint error after simplifier iteration 1 when profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["core-lint","profiling,","simplifier,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This happens with the current development version of Agda, with last change from July 20.\r\n\r\n{{{\r\ndarcs get --lazy http://code.haskell.org/Agda\r\n}}}\r\n\r\nI did:\r\n\r\n{{{\r\n./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcore-lint\r\n./Setup build -v > build.log 2>&1\r\n}}}\r\n\r\n{{{build.log}}} is attached, and shows a core-lint error in the profiling way.\r\n\r\nI tried this since I am getting segfaults and other errors in long Agda runs with more than 4GB heap, and have no idea yet how to trim them down.\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://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/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/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/2712Parallel GC scheduling problems2019-07-07T19:07:13ZSimon MarlowParallel GC scheduling problemsThe parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor...The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.
Really we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.
If this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel GC scheduling problems","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.\r\n\r\nReally we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.\r\n\r\nIf this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1673Template Haskell support for type families2019-07-07T19:12:12Zg9ks157k@acme.softbase.orgTemplate Haskell support for type familiesWould it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------...Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell support for type families","status":"New","operating_system":"Linux","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"FeatureRequest","description":"Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1501Panic in RegisterAlloc2019-07-07T19:13:10ZguestPanic in RegisterAllocThe following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened...The following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened)
(GHC version 6.7.20070620 for i386-unknown-linux):
RegisterAlloc.joinToTargets
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic in RegisterAlloc","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes a panic when compiling with the NCG (i.e. with {{{-fasm}}}).\r\n\r\n{{{\r\nstg_ap_0_fast {\r\n bits32 y, x;\r\n c7: y = bits32[x];\r\n goto c7;\r\n}\r\n}}}\r\n\r\nThe panic is\r\n{{{\r\nghc-6.7.20070620: panic! (the 'impossible' happened)\r\n (GHC version 6.7.20070620 for i386-unknown-linux):\r\n RegisterAlloc.joinToTargets\r\n}}}\r\n\r\nI do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenl