GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-06-20T15:56:29Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5688instance Read Integer/Rational/Double readsPrec out of memory and crash due t...2023-06-20T15:56:29Zgracjaninstance Read Integer/Rational/Double readsPrec out of memory and crash due to exponential notation```
GHCi, version 6.12.3: http://www.haskell.org/ghc/
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ....```
GHCi, version 6.12.3: http://www.haskell.org/ghc/
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
120000000000
Prelude> read "12e1000000000000" :: Integer
Segmentation fault
```
Sometimes it fails with Bus error.
According to Haskell'98 and Haskell'00 Reports Integers should not parse exponential notation at all.
http://www.haskell.org/onlinereport/haskell2010/haskellch2.html\#x7-190002.5
This is security issue in web frameworks as parsing HTTP headers, URLs, JSON and other may involve parsing integers.7.4.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/5899RTS crash w/ strange closure type 603975781 on OS X 10.82021-11-12T10:31:33ZdylukesRTS crash w/ strange closure type 603975781 on OS X 10.8On OS X 10.8 (Mountain Lion, the first developer seed), GHC's RTS crashes with strange closure type 603975781, for almost any program compiled with GHC.
As examples, cpphs and cabal's Setup crash, but a simple `main = putStrLn "hello wo...On OS X 10.8 (Mountain Lion, the first developer seed), GHC's RTS crashes with strange closure type 603975781, for almost any program compiled with GHC.
As examples, cpphs and cabal's Setup crash, but a simple `main = putStrLn "hello world"' does not.
`runhaskell ...' works. It seems this only manifests in compiled programs.
An example of the output can be found here: https://gist.github.com/1918845
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| 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":"GHC RTS crash w/ strange closure type 603975781 on OS X 10.8","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["closure,","error,","internal","os","rts,","strange","x"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On OS X 10.8 (Mountain Lion, the first developer seed), GHC's RTS crashes with strange closure type 603975781, for almost any program compiled with GHC.\r\n\r\nAs examples, cpphs and cabal's Setup crash, but a simple `main = putStrLn \"hello world\"' does not.\r\n\r\n`runhaskell ...' works. It seems this only manifests in compiled programs. \r\n\r\nAn example of the output can be found here: https://gist.github.com/1918845","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/4817Missing new flags description in the user guide2019-10-06T22:18:43ZandresSRMissing new flags description in the user guideIn section 4.8. Warnings and sanity-checking of the user guide, there are not description of the new flags -fwarn-missing-local-sigs
and -fwarn-missing-import-lists. In addition, these warnings are not enabled by -Wall, so this should al...In section 4.8. Warnings and sanity-checking of the user guide, there are not description of the new flags -fwarn-missing-local-sigs
and -fwarn-missing-import-lists. In addition, these warnings are not enabled by -Wall, so this should also be documented.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.0.1 |
| 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":"Missing new flags description in the user guide","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In section 4.8. Warnings and sanity-checking of the user guide, there are not description of the new flags -fwarn-missing-local-sigs\r\nand -fwarn-missing-import-lists. In addition, these warnings are not enabled by -Wall, so this should also be documented.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/3897reading a large String as Double takes too long2019-07-07T19:01:38ZChristian Maederreading a large String as Double takes too long```
Prelude> :set +s
Prelude> read "1e1000000" :: Double
Infinity
(0.46 secs, 8977756 bytes)
Prelude> read "1e1000000000" :: Double
```
The final call takes up all memory and does not terminate
<details><summary>Trac metadata</summary>...```
Prelude> :set +s
Prelude> read "1e1000000" :: Double
Infinity
(0.46 secs, 8977756 bytes)
Prelude> read "1e1000000000" :: Double
```
The final call takes up all memory and does not terminate
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | RuntimePerformance |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"reading a large String as Double takes too long","status":"New","operating_system":"Linux","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"{{{\r\nPrelude> :set +s\r\nPrelude> read \"1e1000000\" :: Double\r\nInfinity\r\n(0.46 secs, 8977756 bytes)\r\nPrelude> read \"1e1000000000\" :: Double\r\n}}}\r\n\r\nThe final call takes up all memory and does not terminate","type_of_failure":"RuntimePerformance","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/4968openTempFile fails on Windows if a directory exists with the file name it tries2019-07-07T18:57:34ZganeshopenTempFile fails on Windows if a directory exists with the file name it triesThe program below works on Linux but fails on Windows with "permission denied" from the second openTempFile.
I think the reason is that findTempName in the openTempFile source doesn't get eEXIST when a directory with the same name exist...The program below works on Linux but fails on Windows with "permission denied" from the second openTempFile.
I think the reason is that findTempName in the openTempFile source doesn't get eEXIST when a directory with the same name exists, so it fails instead of trying again.
The real use case behind this code is making temp directories on multiple threads simultaneously.
```
import Prelude
import System.IO
import System.Directory
main :: IO ()
main = do
dir <- getTemporaryDirectory
(npath1, handle1) <- openTempFile dir "tmp"
hClose handle1
removeFile npath1
createDirectory npath1
(npath2, handle2) <- openTempFile dir "tmp"
return ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh@earth.li |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"openTempFile fails on Windows if a directory exists with the file name it tries","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ganesh@earth.li"],"type":"Bug","description":"The program below works on Linux but fails on Windows with \"permission denied\" from the second openTempFile.\r\n\r\nI think the reason is that findTempName in the openTempFile source doesn't get eEXIST when a directory with the same name exists, so it fails instead of trying again.\r\n\r\nThe real use case behind this code is making temp directories on multiple threads simultaneously.\r\n\r\n\r\n{{{\r\nimport Prelude\r\nimport System.IO\r\nimport System.Directory\r\n\r\nmain :: IO ()\r\nmain = do\r\n dir <- getTemporaryDirectory\r\n (npath1, handle1) <- openTempFile dir \"tmp\"\r\n hClose handle1\r\n removeFile npath1\r\n createDirectory npath1\r\n (npath2, handle2) <- openTempFile dir \"tmp\"\r\n return ()\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/5072Segfault on OS X in interpreted code2019-07-07T18:57:01Znominolo@gmail.comSegfault on OS X in interpreted codeI'm getting reproducable segfaults/GC panics when doing the following:
```
$ ghci -package ghc Scion/Config.hs
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package...I'm getting reproducable segfaults/GC panics when doing the following:
```
$ ghci -package ghc Scion/Config.hs
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.2.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package pretty-1.0.1.2 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package Cabal-1.10.1.0 ... linking ... done.
Loading package bytestring-0.9.1.10 ... linking ... done.
Loading package ghc-binary-0.5.0.2 ... linking ... done.
Loading package bin-package-db-0.0.0.0 ... linking ... done.
Loading package hpc-0.5.0.6 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package ghc-7.0.2 ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 6] Compiling Scion.Types.ExtraInstances ( Scion/Types/ExtraInstances.hs, interpreted )
[2 of 6] Compiling Scion.Types.Notes ( Scion/Types/Notes.hs, interpreted )
[3 of 6] Compiling Scion.Types.DefinitionSites ( Scion/Types/DefinitionSites.hs, interpreted )
[4 of 6] Compiling Scion.Types.Session ( Scion/Types/Session.hs, interpreted )
[5 of 6] Compiling Scion.Types ( Scion/Types.hs, interpreted )
[6 of 6] Compiling Scion.Config ( Scion/Config.hs, interpreted )
Ok, modules loaded: Scion.Config, Scion.Types, Scion.Types.Session, Scion.Types.Notes, Scion.Types.DefinitionSites, Scion.Types.ExtraInstances.
*Scion.Config> test_config
Loading package time-1.2.0.3 ... linking ... done.
Loading package attoparsec-0.8.5.0 ... linking ... done.
Loading package deepseq-1.1.0.2 ... linking ... done.
Loading package text-0.11.0.5 ... linking ... done.
Loading package blaze-builder-0.3.0.0 ... linking ... done.
Loading package binary-0.5.0.2 ... linking ... done.
Loading package bytestring-show-0.3.4 ... linking ... done.
Loading package hashable-1.1.1.0 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package monads-fd-0.2.0.0 ... linking ... done.
Loading package syb-0.3 ... linking ... done.
Loading package unordered-containers-0.1.2.0 ... linking ... done.
Loading package primitive-0.3.1 ... linking ... done.
Loading package vector-0.7.0.1 ... linking ... done.
Loading package aeson-0.3.2.1 ... linking ... done.
Loading package multiset-0.2.1 ... linking ... done.
key "filename" not present
*Scion.Config> ghc: internal error: evacuate: strange closure type 1085528
(GHC version 7.0.2 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
After running `test_config` it takes a few seconds for the panic to occur. If I compile the first five files, the panic seems to disappear, so my guess it is some problem with interpreted code:
```
$ ghc --make -package ghc Scion.Types
...
$ ghci -package ghc Scion/Config.hs
*Scion.Config> test_config
-- no segfault
*Scion.Config> :q
Leaving GHCi.
$ rm Scion/Types.hi
$ rm Scion/Types.o
$ ghci -package ghc Scion/Config.hs
*Scion.Config> test_config
... (loading packages) ...
*Scion.Config> ghc: internal error: evacuate: strange closure type 66664
(GHC version 7.0.2 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
I attached the source files. You'll need additional packages, though. See the full output above for which ones these are.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"Segfault on OS X in interpreted code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm getting reproducable segfaults/GC panics when doing the following:\r\n\r\n{{{\r\n$ ghci -package ghc Scion/Config.hs \r\nGHCi, version 7.0.2: 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\nLoading package array-0.3.0.2 ... linking ... done.\r\nLoading package containers-0.4.0.0 ... linking ... done.\r\nLoading package filepath-1.2.0.0 ... linking ... done.\r\nLoading package old-locale-1.0.0.2 ... linking ... done.\r\nLoading package old-time-1.0.0.6 ... linking ... done.\r\nLoading package unix-2.4.2.0 ... linking ... done.\r\nLoading package directory-1.1.0.0 ... linking ... done.\r\nLoading package pretty-1.0.1.2 ... linking ... done.\r\nLoading package process-1.0.1.5 ... linking ... done.\r\nLoading package Cabal-1.10.1.0 ... linking ... done.\r\nLoading package bytestring-0.9.1.10 ... linking ... done.\r\nLoading package ghc-binary-0.5.0.2 ... linking ... done.\r\nLoading package bin-package-db-0.0.0.0 ... linking ... done.\r\nLoading package hpc-0.5.0.6 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package ghc-7.0.2 ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 6] Compiling Scion.Types.ExtraInstances ( Scion/Types/ExtraInstances.hs, interpreted )\r\n[2 of 6] Compiling Scion.Types.Notes ( Scion/Types/Notes.hs, interpreted )\r\n[3 of 6] Compiling Scion.Types.DefinitionSites ( Scion/Types/DefinitionSites.hs, interpreted )\r\n[4 of 6] Compiling Scion.Types.Session ( Scion/Types/Session.hs, interpreted )\r\n[5 of 6] Compiling Scion.Types ( Scion/Types.hs, interpreted )\r\n[6 of 6] Compiling Scion.Config ( Scion/Config.hs, interpreted )\r\nOk, modules loaded: Scion.Config, Scion.Types, Scion.Types.Session, Scion.Types.Notes, Scion.Types.DefinitionSites, Scion.Types.ExtraInstances.\r\n*Scion.Config> test_config \r\nLoading package time-1.2.0.3 ... linking ... done.\r\nLoading package attoparsec-0.8.5.0 ... linking ... done.\r\nLoading package deepseq-1.1.0.2 ... linking ... done.\r\nLoading package text-0.11.0.5 ... linking ... done.\r\nLoading package blaze-builder-0.3.0.0 ... linking ... done.\r\nLoading package binary-0.5.0.2 ... linking ... done.\r\nLoading package bytestring-show-0.3.4 ... linking ... done.\r\nLoading package hashable-1.1.1.0 ... linking ... done.\r\nLoading package transformers-0.2.2.0 ... linking ... done.\r\nLoading package mtl-2.0.1.0 ... linking ... done.\r\nLoading package monads-fd-0.2.0.0 ... linking ... done.\r\nLoading package syb-0.3 ... linking ... done.\r\nLoading package unordered-containers-0.1.2.0 ... linking ... done.\r\nLoading package primitive-0.3.1 ... linking ... done.\r\nLoading package vector-0.7.0.1 ... linking ... done.\r\nLoading package aeson-0.3.2.1 ... linking ... done.\r\nLoading package multiset-0.2.1 ... linking ... done.\r\nkey \"filename\" not present\r\n*Scion.Config> ghc: internal error: evacuate: strange closure type 1085528\r\n (GHC version 7.0.2 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n\r\nAfter running `test_config` it takes a few seconds for the panic to occur. If I compile the first five files, the panic seems to disappear, so my guess it is some problem with interpreted code:\r\n\r\n{{{\r\n$ ghc --make -package ghc Scion.Types\r\n...\r\n$ ghci -package ghc Scion/Config.hs\r\n*Scion.Config> test_config\r\n-- no segfault\r\n*Scion.Config> :q\r\nLeaving GHCi.\r\n\r\n$ rm Scion/Types.hi\r\n$ rm Scion/Types.o\r\n$ ghci -package ghc Scion/Config.hs\r\n*Scion.Config> test_config\r\n... (loading packages) ...\r\n*Scion.Config> ghc: internal error: evacuate: strange closure type 66664\r\n (GHC version 7.0.2 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n\r\nI attached the source files. You'll need additional packages, though. See the full output above for which ones these are.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5214SIGSEGV in yieldCapability ()2019-07-07T18:56:23Zwaldmann@imn.htwk-leipzig.deSIGSEGV in yieldCapability ()the following happens in a program compiled with ghc-7.0.3
(and also, with ghc-6.12.3), running with +RTS -N
on i7-920, ubuntu 11 (kernel 2.6.38-8)
```
Program received signal SIGSEGV, Segmentation fault.
0x00000000006071de in yieldCapa...the following happens in a program compiled with ghc-7.0.3
(and also, with ghc-6.12.3), running with +RTS -N
on i7-920, ubuntu 11 (kernel 2.6.38-8)
```
Program received signal SIGSEGV, Segmentation fault.
0x00000000006071de in yieldCapability ()
(gdb) where
#0 0x00000000006071de in yieldCapability ()
#1 0x000000000060bc6b in schedule ()
#2 0x0000000000609294 in real_main ()
#3 0x000000000060938d in hs_main ()
#4 0x00007ffff6b07eff in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#5 0x000000000040a589 in _start ()
```
cf. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/89244
My program uses STM and FFI.
I am working on boiling down a test case.
I open this ticket to perhaps get some directions.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| 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":"SIGSEGV in yieldCapability ()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"the following happens in a program compiled with ghc-7.0.3\r\n(and also, with ghc-6.12.3), running with +RTS -N\r\non i7-920, ubuntu 11 (kernel 2.6.38-8)\r\n\r\n{{{\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n0x00000000006071de in yieldCapability ()\r\n(gdb) where\r\n#0 0x00000000006071de in yieldCapability ()\r\n#1 0x000000000060bc6b in schedule ()\r\n#2 0x0000000000609294 in real_main ()\r\n#3 0x000000000060938d in hs_main ()\r\n#4 0x00007ffff6b07eff in __libc_start_main ()\r\n from /lib/x86_64-linux-gnu/libc.so.6\r\n#5 0x000000000040a589 in _start ()\r\n}}}\r\n\r\ncf. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/89244\r\n\r\nMy program uses STM and FFI.\r\nI am working on boiling down a test case.\r\nI open this ticket to perhaps get some directions.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5337mkRtsOptionsLevelObj should respect -optc standard headers2019-07-07T18:55:50ZgnezdomkRtsOptionsLevelObj should respect -optc standard headersOur fancy compilation environment does not keep the standard C headers always in the same place. We always invoke gcc with --sysroot. Then we pass the same flag to ghc with -optc--sysroot=blah.
This works most of the time until I also d...Our fancy compilation environment does not keep the standard C headers always in the same place. We always invoke gcc with --sysroot. Then we pass the same flag to ghc with -optc--sysroot=blah.
This works most of the time until I also do ghc -rtsopts. In that case GHC will try to build a small generated object file with a limited command line that fails to include -optc flags. That leads to failure:
```
*** C Compiler:
gcc -c /tmp/ghc15472_0/ghc15472_0.c -o /tmp/ghc15472_0/ghc15472_0.o -Ilib/ghc-7.0.4/include -fno-stack-protector
In file included from /tmp/ghc15472_0/ghc15472_0.c:1:0:
In file included from lib/ghc-7.0.4/include/Rts.h:23:0:
lib/ghc-7.0.4/include/Stg.h:62:10:
fatal error: 'math.h' file not found
#include <math.h>
^
1 error generated.
```
This seems trivially easy to fix with the attached patch.7.4.2pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/5343ghci should do an automatic ":r" after ":e"2019-07-07T18:55:48ZLevent Erkökghci should do an automatic ":r" after ":e"A reload (:r) is almost always what one does after an edit (:e). Arguably ghci should just do the :r after an :e automatically, as I can't imagine why someone would edit a file but not want to load it back into ghci.
If memory serves th...A reload (:r) is almost always what one does after an edit (:e). Arguably ghci should just do the :r after an :e automatically, as I can't imagine why someone would edit a file but not want to load it back into ghci.
If memory serves this is how hugs used to work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| 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":"ghci should do an automatic \":r\" after \":e\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"A reload (:r) is almost always what one does after an edit (:e). Arguably ghci should just do the :r after an :e automatically, as I can't imagine why someone would edit a file but not want to load it back into ghci.\r\n\r\nIf memory serves this is how hugs used to work.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/5534ghci -fobject-code strangeness2019-07-07T18:54:52ZSimon Marlowghci -fobject-code strangenessWith this `Foo.hs`:
```
module Foo (b) where
a = 2
b = 3
c = 4
```
I get this strange behaviour:
```
> ghci -fobject-code
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Lo...With this `Foo.hs`:
```
module Foo (b) where
a = 2
b = 3
c = 4
```
I get this strange behaviour:
```
> ghci -fobject-code
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :l foo
[1 of 1] Compiling Foo ( foo.hs, foo.o )
Ok, modules loaded: Foo.
*Foo> :browse
b :: Integer
*Foo> a
<interactive>:1:1:
Can't find interface-file declaration for variable a
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the expression: a
In an equation for `it': it = a
*Foo>
```
So `a` is in scope, but it can't be used. Furthermore, `:browse *Foo` does not show `a` or `c` (it does without `-fobject-code`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| 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":"ghci -fobject-code strangeness","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With this `Foo.hs`:\r\n\r\n{{{\r\nmodule Foo (b) where\r\n\r\na = 2\r\nb = 3\r\nc = 4\r\n}}}\r\n\r\nI get this strange behaviour:\r\n\r\n{{{\r\n> ghci -fobject-code\r\nGHCi, version 7.0.3: 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\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> :l foo\r\n[1 of 1] Compiling Foo ( foo.hs, foo.o )\r\nOk, modules loaded: Foo.\r\n*Foo> :browse\r\nb :: Integer\r\n*Foo> a\r\n\r\n<interactive>:1:1:\r\n Can't find interface-file declaration for variable a\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n In the expression: a\r\n In an equation for `it': it = a\r\n*Foo> \r\n}}}\r\n\r\nSo `a` is in scope, but it can't be used. Furthermore, `:browse *Foo` does not show `a` or `c` (it does without `-fobject-code`).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5568Add Show and Binary instances for TypeRep2019-07-07T18:54:41ZSimon MarlowAdd Show and Binary instances for TypeRep(was a re-opening of #3480; copied into a new ticket so we can leave #3480 dead and buried)
Unfortunately the new !TypeRepKey type is abstract and provides no operations apart from Eq and Ord instances. Hence, there is still no way to w...(was a re-opening of #3480; copied into a new ticket so we can leave #3480 dead and buried)
Unfortunately the new !TypeRepKey type is abstract and provides no operations apart from Eq and Ord instances. Hence, there is still no way to write a type representation into a file or across the wire. Jush showing a !TypeRep won't cut it, since that loses the distinctions between similarly named types in different modules.
So, I think we need a Show instance for !TypeRepKey, or better yet, a Binary instance. Moreover, a non-deprecated pure function `TypeRep -> TypeRepKey` is in place, since the keys have an actual use as a compact, efficient, and serializable injection of the typereps.
Alternatively, the Show instance of !TypeRep could be made injective by printing out the package and module.
### Commentary from #3480
simonmar says:
> I've exposed the representation via the Data.Typeable.Internal module. Of course that's not guaranteed to be a stable API, but I'm happy to add a stable API if we can agree on what it should be. Lennart Augustsson and Neil Mitchell are doing exactly this (serialising !TypeRep) - I think they're using the Data.Typeable.Internal API right now.
> So what shall we do?
Lennart says:
> For older versions of ghc I just used (show . typeOf). When ghc 7.2 broke this I had to start using Internal, so now I use tyConModule and tyConName to emulate the behaviour of the old show.
lealanko says:
> I'm sorry for messing up the ticket. I had assumed that the missing Show instance had been a simple oversight. If so, this would suffice:
```
instance Show TypeRepKey where
show (TypeRepKey (Fingerprint hi lo)) = printf "%016x%016x" hi lo
```
> A Binary instance is more difficult: where would it be put? It cannot be in Typeable.hs (as base cannot depend on binary), but it cannot be in Binary.hs either (as !TypeRepKey is opaque and not exposed from Typeable).
> I don't think it's a good idea to make TypeReps themselves publicly deserializable, as that would allow the creation of fake typereps. A separate one-way injection to a serializable !TypeRepKey seems much more secure.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| 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":"Add Show and Binary instances for TypeRep","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(was a re-opening of #3480; copied into a new ticket so we can leave #3480 dead and buried)\r\n\r\nUnfortunately the new !TypeRepKey type is abstract and provides no operations apart from Eq and Ord instances. Hence, there is still no way to write a type representation into a file or across the wire. Jush showing a !TypeRep won't cut it, since that loses the distinctions between similarly named types in different modules.\r\n\r\nSo, I think we need a Show instance for !TypeRepKey, or better yet, a Binary instance. Moreover, a non-deprecated pure function `TypeRep -> TypeRepKey` is in place, since the keys have an actual use as a compact, efficient, and serializable injection of the typereps.\r\n\r\nAlternatively, the Show instance of !TypeRep could be made injective by printing out the package and module.\r\n\r\n=== Commentary from #3480 ===\r\n\r\nsimonmar says:\r\n\r\n I've exposed the representation via the Data.Typeable.Internal module. Of course that's not guaranteed to be a stable API, but I'm happy to add a stable API if we can agree on what it should be. Lennart Augustsson and Neil Mitchell are doing exactly this (serialising !TypeRep) - I think they're using the Data.Typeable.Internal API right now.\r\n\r\n So what shall we do? \r\n\r\nLennart says:\r\n\r\n For older versions of ghc I just used (show . typeOf). When ghc 7.2 broke this I had to start using Internal, so now I use tyConModule and tyConName to emulate the behaviour of the old show. \r\n\r\nlealanko says:\r\n\r\n I'm sorry for messing up the ticket. I had assumed that the missing Show instance had been a simple oversight. If so, this would suffice:\r\n\r\n{{{\r\ninstance Show TypeRepKey where\r\n show (TypeRepKey (Fingerprint hi lo)) = printf \"%016x%016x\" hi lo\r\n}}}\r\n\r\n A Binary instance is more difficult: where would it be put? It cannot be in Typeable.hs (as base cannot depend on binary), but it cannot be in Binary.hs either (as !TypeRepKey is opaque and not exposed from Typeable).\r\n\r\n I don't think it's a good idea to make TypeReps themselves publicly deserializable, as that would allow the creation of fake typereps. A separate one-way injection to a serializable !TypeRepKey seems much more secure.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5623GHC 7.2.1 Performance Regression: Vector2019-07-07T18:54:19ZdtereiGHC 7.2.1 Performance Regression: VectorThis program shows a severe performance drop under GHC 7.2.1 compared to GHC 7.0.4. I've tested with GHC HEAD and the performance drop is still there.
```
{-# LANGUAGE BangPatterns #-}
{-
ghc 6.12.1 -O2
1.752
-}
import Data.Ve...This program shows a severe performance drop under GHC 7.2.1 compared to GHC 7.0.4. I've tested with GHC HEAD and the performance drop is still there.
```
{-# LANGUAGE BangPatterns #-}
{-
ghc 6.12.1 -O2
1.752
-}
import Data.Vector.Storable
import qualified Data.Vector.Storable as V
import Foreign
import Foreign.C.Types
-- Define a 4 element vector type
data Vec4 = Vec4 {-# UNPACK #-} !CFloat
{-# UNPACK #-} !CFloat
{-# UNPACK #-} !CFloat
{-# UNPACK #-} !CFloat
------------------------------------------------------------------------
-- Ensure we can store it in an array
instance Storable Vec4 where
sizeOf _ = sizeOf (undefined :: CFloat) * 4
alignment _ = alignment (undefined :: CFloat)
{-# INLINE peek #-}
peek p = do
a <- peekElemOff q 0
b <- peekElemOff q 1
c <- peekElemOff q 2
d <- peekElemOff q 3
return (Vec4 a b c d)
where
q = castPtr p
{-# INLINE poke #-}
poke p (Vec4 a b c d) = do
pokeElemOff q 0 a
pokeElemOff q 1 b
pokeElemOff q 2 c
pokeElemOff q 3 d
where
q = castPtr p
------------------------------------------------------------------------
a = Vec4 0.2 0.1 0.6 1.0
m = Vec4 0.99 0.7 0.8 0.6
add :: Vec4 -> Vec4 -> Vec4
{-# INLINE add #-}
add (Vec4 a b c d) (Vec4 a' b' c' d') = Vec4 (a+a') (b+b') (c+c') (d+d')
mult :: Vec4 -> Vec4 -> Vec4
{-# INLINE mult #-}
mult (Vec4 a b c d) (Vec4 a' b' c' d') = Vec4 (a*a') (b*b') (c*c') (d*d')
vsum :: Vec4 -> CFloat
{-# INLINE vsum #-}
vsum (Vec4 a b c d) = a+b+c+d
multList :: Int -> Vector Vec4 -> Vector Vec4
multList !count !src
| count <= 0 = src
| otherwise = multList (count-1) $ V.map (\v -> add (mult v m) a) src
main = do
print $ Data.Vector.Storable.sum
$ Data.Vector.Storable.map vsum
$ multList repCount
$ Data.Vector.Storable.replicate arraySize (Vec4 0 0 0 0)
repCount, arraySize :: Int
repCount = 10000
arraySize = 20000
```
Timings on my machine:
```
* GHC 7.0.3 (-fasm -O2): 1.481s
* GHC 7.2.1 (-fasm -O2): 2.050s
* GHC HEAD (-fasm -O2): 2.051s
```
The bug occurs with the llvm backend as well, but just test with '-fasm' as this test case came from a different performance bug specific to the llvm backend I was tracking (#4223).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"GHC 7.2.1 Performance Regression: Vector","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program shows a severe performance drop under GHC 7.2.1 compared to GHC 7.0.4. I've tested with GHC HEAD and the performance drop is still there.\r\n\r\n{{{\r\n{-# LANGUAGE BangPatterns #-}\r\n\r\n{-\r\n ghc 6.12.1 -O2\r\n 1.752\r\n-}\r\n\r\nimport Data.Vector.Storable\r\nimport qualified Data.Vector.Storable as V\r\nimport Foreign\r\nimport Foreign.C.Types\r\n\r\n-- Define a 4 element vector type\r\ndata Vec4 = Vec4 {-# UNPACK #-} !CFloat\r\n {-# UNPACK #-} !CFloat\r\n {-# UNPACK #-} !CFloat\r\n {-# UNPACK #-} !CFloat\r\n\r\n------------------------------------------------------------------------\r\n\r\n-- Ensure we can store it in an array\r\ninstance Storable Vec4 where\r\n sizeOf _ = sizeOf (undefined :: CFloat) * 4\r\n alignment _ = alignment (undefined :: CFloat)\r\n\r\n {-# INLINE peek #-}\r\n peek p = do\r\n a <- peekElemOff q 0\r\n b <- peekElemOff q 1\r\n c <- peekElemOff q 2\r\n d <- peekElemOff q 3\r\n return (Vec4 a b c d)\r\n where\r\n q = castPtr p\r\n\r\n {-# INLINE poke #-}\r\n poke p (Vec4 a b c d) = do\r\n pokeElemOff q 0 a\r\n pokeElemOff q 1 b\r\n pokeElemOff q 2 c\r\n pokeElemOff q 3 d\r\n where\r\n q = castPtr p\r\n\r\n------------------------------------------------------------------------\r\n\r\na = Vec4 0.2 0.1 0.6 1.0\r\nm = Vec4 0.99 0.7 0.8 0.6\r\n\r\nadd :: Vec4 -> Vec4 -> Vec4\r\n{-# INLINE add #-}\r\nadd (Vec4 a b c d) (Vec4 a' b' c' d') = Vec4 (a+a') (b+b') (c+c') (d+d')\r\n\r\nmult :: Vec4 -> Vec4 -> Vec4\r\n{-# INLINE mult #-}\r\nmult (Vec4 a b c d) (Vec4 a' b' c' d') = Vec4 (a*a') (b*b') (c*c') (d*d')\r\n\r\nvsum :: Vec4 -> CFloat\r\n{-# INLINE vsum #-}\r\nvsum (Vec4 a b c d) = a+b+c+d\r\n\r\nmultList :: Int -> Vector Vec4 -> Vector Vec4\r\nmultList !count !src\r\n | count <= 0 = src\r\n | otherwise = multList (count-1) $ V.map (\\v -> add (mult v m) a) src\r\n\r\nmain = do\r\n print $ Data.Vector.Storable.sum\r\n $ Data.Vector.Storable.map vsum\r\n $ multList repCount\r\n $ Data.Vector.Storable.replicate arraySize (Vec4 0 0 0 0)\r\n\r\nrepCount, arraySize :: Int\r\nrepCount = 10000\r\narraySize = 20000\r\n}}}\r\n\r\nTimings on my machine:\r\n{{{\r\n * GHC 7.0.3 (-fasm -O2): 1.481s\r\n * GHC 7.2.1 (-fasm -O2): 2.050s\r\n * GHC HEAD (-fasm -O2): 2.051s\r\n}}}\r\nThe bug occurs with the llvm backend as well, but just test with '-fasm' as this test case came from a different performance bug specific to the llvm backend I was tracking (#4223).","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5670Document that Enum Integer is subject to list fusion.2019-07-07T18:54:06ZJoachim Breitnermail@joachim-breitner.deDocument that Enum Integer is subject to list fusion.The documentation does not mention it, but it is the case (verified in 7.0.4), so the docu should reflect that. Trivial patch attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...The documentation does not mention it, but it is the case (verified in 7.0.4), so the docu should reflect that. Trivial patch attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.0.4 |
| 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":"Document that Enum Integer is subject to list fusion.","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The documentation does not mention it, but it is the case (verified in 7.0.4), so the docu should reflect that. Trivial patch attached.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5704Bug in the handling of wired-in packages (like template-haskell)2019-07-07T18:53:58ZSimon MarlowBug in the handling of wired-in packages (like template-haskell)If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.
This happened when trying to build `aeson-0.4.0.0` wit...If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.
This happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson` requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0. Cabal installed `template-haskell-2.6.0.0`, but while building `aeson` against it we get:
```
Data/Aeson/TH.hs:181:1:
Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi
Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH
```
the bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0` to be the wired-in package:
```
wired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace
```
whereas we wanted to use `template-haskell-2.6.0.0`.
Not immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in `aeson` to allow `template-haskell-2.7.0.0`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in the handling of wired-in packages (like template-haskell)","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the \"wired-in\" package rather than the older one.\r\n\r\nThis happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson` requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0. Cabal installed `template-haskell-2.6.0.0`, but while building `aeson` against it we get:\r\n\r\n{{{\r\nData/Aeson/TH.hs:181:1:\r\n Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi\r\n Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH\r\n}}}\r\n\r\nthe bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0` to be the wired-in package:\r\n\r\n{{{\r\nwired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace\r\n}}}\r\n\r\nwhereas we wanted to use `template-haskell-2.6.0.0`.\r\n\r\nNot immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in `aeson` to allow `template-haskell-2.7.0.0`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5715Inliner fails to inline a function, causing 20x slowdown2019-07-07T18:53:55ZbosInliner fails to inline a function, causing 20x slowdownAlexey filed [a bug against the mwc-random package recently](https://github.com/bos/mwc-random/pull/6), indicating a 20x to 40x slowdown on a function named `uniformRange` - [you can see its source here](https://github.com/bos/mwc-random...Alexey filed [a bug against the mwc-random package recently](https://github.com/bos/mwc-random/pull/6), indicating a 20x to 40x slowdown on a function named `uniformRange` - [you can see its source here](https://github.com/bos/mwc-random/blob/d7fda635bdd7a4d03ad8649e26ffa6d2b9b4c400/System/Random/MWC.hs#L487).
In the original definition, there was an `INLINE` pragma, but Alexey noticed that it wasn't firing and so performance was predictably terrible. He added the `SPECIALIZE` pragmas that now follow the body of the function.
I looked at `-ddump-simpl` output with the `SPECIALIZE` pragmas removed, and sure enough there are no inlining annotations on the function.
The whole purpose of `uniformRange` is to be used in instance declarations such as the following:
```
instance Variate Int8 where
uniform = uniform1 fromIntegral
uniformR = uniformRange
{-# INLINE uniform #-}
{-# INLINE uniformR #-}
```
I have a suspicion that what's going on is that GHC's inliner is declining to do anything because some call site or other (or perhaps several?) isn't fully saturated.
The behaviour of the new inliner is subtle to understand at times - it's not at all obvious when I should rewrite an instance like this, just to satisfy it:
```
instance Variate Int8 where
uniform = uniform1 fromIntegral
uniformR inliner sacrifice = uniformRange inliner sacrifice
{-# INLINE uniform #-}
{-# INLINE uniformR #-}
```
Saturating as above turned out to be the solution to the performance problem. I've been able to remove the `SPECIALIZE` pragmas. However, I'm still worried.
It would be helpful if GHC had a mode that dumped out when (and why) inlinings do \*not\* take place on functions that have been annotated with `INLINE`, because I'm surely not the only person who gets caught by this.
Also, aesthetically I find that saturating an application as above makes for tricky-to-read "why are those arguments there?" code, sort of the inliner's version of the dreaded monomorphism restriction: a lexical tic that's tremendously important, but for reasons that most readers will not know about.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.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":"Inliner fails to inline a function, causing 20x slowdown","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Alexey filed [https://github.com/bos/mwc-random/pull/6 a bug against the mwc-random package recently], indicating a 20x to 40x slowdown on a function named `uniformRange` - [https://github.com/bos/mwc-random/blob/d7fda635bdd7a4d03ad8649e26ffa6d2b9b4c400/System/Random/MWC.hs#L487 you can see its source here].\r\n\r\nIn the original definition, there was an `INLINE` pragma, but Alexey noticed that it wasn't firing and so performance was predictably terrible. He added the `SPECIALIZE` pragmas that now follow the body of the function.\r\n\r\nI looked at `-ddump-simpl` output with the `SPECIALIZE` pragmas removed, and sure enough there are no inlining annotations on the function.\r\n\r\nThe whole purpose of `uniformRange` is to be used in instance declarations such as the following:\r\n\r\n{{{\r\ninstance Variate Int8 where\r\n uniform = uniform1 fromIntegral\r\n uniformR = uniformRange\r\n {-# INLINE uniform #-}\r\n {-# INLINE uniformR #-}\r\n}}}\r\n\r\nI have a suspicion that what's going on is that GHC's inliner is declining to do anything because some call site or other (or perhaps several?) isn't fully saturated.\r\n\r\nThe behaviour of the new inliner is subtle to understand at times - it's not at all obvious when I should rewrite an instance like this, just to satisfy it:\r\n\r\n{{{\r\ninstance Variate Int8 where\r\n uniform = uniform1 fromIntegral\r\n uniformR inliner sacrifice = uniformRange inliner sacrifice\r\n {-# INLINE uniform #-}\r\n {-# INLINE uniformR #-}\r\n}}}\r\n\r\nSaturating as above turned out to be the solution to the performance problem. I've been able to remove the `SPECIALIZE` pragmas. However, I'm still worried.\r\n\r\nIt would be helpful if GHC had a mode that dumped out when (and why) inlinings do *not* take place on functions that have been annotated with `INLINE`, because I'm surely not the only person who gets caught by this.\r\n\r\nAlso, aesthetically I find that saturating an application as above makes for tricky-to-read \"why are those arguments there?\" code, sort of the inliner's version of the dreaded monomorphism restriction: a lexical tic that's tremendously important, but for reasons that most readers will not know about.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5716Failure when using promoted data family instances2019-07-07T18:53:55ZdreixelFailure when using promoted data family instancesThe following code should fail (since we don't promote data families), but it should do so gracefully:
```
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE PolyKinds #...The following code should fail (since we don't promote data families), but it should do so gracefully:
```
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE PolyKinds #-}
module Bug1 where
data family DF a
data instance DF Int = DFInt
data U = U1 (DF Int)
data I :: U -> * where I1 :: I (U1 DFInt)
{-
GHC internal error: `DFInt' is not in scope during type checking, but it passed the renamer
tcl_env of environment: [(r9P, AThing U -> *), (r9Q, ANothing)]
In the type `I (U1 DFInt)'
In the definition of data constructor `I1'
In the data type declaration for `I'
-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | jpm@cs.uu.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Failure when using promoted data family instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["jpm@cs.uu.nl"],"type":"Bug","description":"The following code should fail (since we don't promote data families), but it should do so gracefully:\r\n{{{\r\n\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n\r\nmodule Bug1 where\r\n\r\n\r\ndata family DF a \r\ndata instance DF Int = DFInt\r\n\r\ndata U = U1 (DF Int)\r\n\r\ndata I :: U -> * where I1 :: I (U1 DFInt)\r\n\r\n{-\r\n GHC internal error: `DFInt' is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [(r9P, AThing U -> *), (r9Q, ANothing)]\r\n In the type `I (U1 DFInt)'\r\n In the definition of data constructor `I1'\r\n In the data type declaration for `I'\r\n-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5721Panic when quoting a scoped type variable2019-07-07T18:53:53ZbenmachinePanic when quoting a scoped type variable```
{-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
module GetNameOfThing where
import Language.Haskell.TH
f :: a -> Name
f (x :: a) = ''a
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.2 for i386-unknown-lin...```
{-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
module GetNameOfThing where
import Language.Haskell.TH
f :: a -> Name
f (x :: a) = ''a
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.2 for i386-unknown-linux):
th_bracket a{tv ahF}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The function is probably nonsense, but the error message could be friendlier.
Tested on GHC 7.2.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic when quoting a scoped type variable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":["haskell,","scoped","template","type","variables"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}\r\nmodule GetNameOfThing where\r\n\r\nimport Language.Haskell.TH\r\n\r\nf :: a -> Name\r\nf (x :: a) = ''a\r\n}}}\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.2.2 for i386-unknown-linux):\r\n\tth_bracket a{tv ahF}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\nThe function is probably nonsense, but the error message could be friendlier.\r\n\r\nTested on GHC 7.2.2.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5727Unclear documentation about .eventlog's spark information flag2019-07-07T18:53:52Zshelarcy@capella.freemail.ne.jpUnclear documentation about .eventlog's spark information flagUnclear documentation about .eventlog's spark information flag
GHC 7.4.1 RC 1 User's Guide just describes that -l option's p flag enable/disable sampled result and f enable/disable flag fully accurate result.
- http://www.haskell.org/g...Unclear documentation about .eventlog's spark information flag
GHC 7.4.1 RC 1 User's Guide just describes that -l option's p flag enable/disable sampled result and f enable/disable flag fully accurate result.
- http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/runtime-control.html\#rts-eventlog
But when enabled f without enabled p flag, .eventlog file doesn't have any useful information about sparks.
```
$ ./ParallelTest +RTS -l-af
```
```
$ ./ParallelTest +RTS -l-pf
```
If f flag requires p flag, please document that or change f flag's behavior.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.3 |
| 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":"Unclear documentation about .eventlog's spark information flag","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"duncan"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Unclear documentation about .eventlog's spark information flag\r\n\r\nGHC 7.4.1 RC 1 User's Guide just describes that -l option's p flag enable/disable sampled result and f enable/disable flag fully accurate result. \r\n\r\n * http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/runtime-control.html#rts-eventlog\r\n\r\nBut when enabled f without enabled p flag, .eventlog file doesn't have any useful information about sparks.\r\n\r\n{{{\r\n$ ./ParallelTest +RTS -l-af\r\n}}}\r\n\r\n{{{\r\n$ ./ParallelTest +RTS -l-pf\r\n}}}\r\n\r\nIf f flag requires p flag, please document that or change f flag's behavior.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/5776Rule matching regression2019-07-07T18:53:39Zrl@cse.unsw.edu.auRule matching regressionThis shows up in the Quickhull benchmark from the `vector` package. I haven't been able to come up with a smaller example so far. To reproduce, download `vector-0.9.1`, compile `benchmarks/Algo/Quickhull.hs` with `-O2` and look at the ou...This shows up in the Quickhull benchmark from the `vector` package. I haven't been able to come up with a smaller example so far. To reproduce, download `vector-0.9.1`, compile `benchmarks/Algo/Quickhull.hs` with `-O2` and look at the output of simplifier phase 2.
The bit in question is this (in `hsplit`, in the let-binding for `packed`):
```
(Data.Vector.Generic.stream
@ Data.Vector.Unboxed.Base.Vector
@ ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)
$dVector_a1uD
(Data.Vector.Generic.new
@ Data.Vector.Unboxed.Base.Vector
@ ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)
$dVector_a1nZ
(Data.Vector.Generic.New.unstream
@ Data.Vector.Unboxed.Base.Vector
@ ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)
$dVector_a1nZ
...
```
The two dictionaries here are actually equivalent:
```
$dVector_a1nZ
:: Data.Vector.Generic.Base.Vector
Data.Vector.Unboxed.Base.Vector
((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)
$dVector_a1nZ =
Data.Vector.Unboxed.Base.$fVectorVector(,)
@ (GHC.Types.Double, GHC.Types.Double)
@ GHC.Types.Double
$dUnbox_s1ne
Data.Vector.Unboxed.Base.$fUnboxDouble
$dVector_a1uD
:: Data.Vector.Generic.Base.Vector
Data.Vector.Unboxed.Base.Vector
((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)
$dVector_a1uD =
Data.Vector.Unboxed.Base.$fVectorVector(,)
@ (GHC.Types.Double, GHC.Types.Double)
@ GHC.Types.Double
$dUnbox_s1ne
Data.Vector.Unboxed.Base.$fUnboxDouble
```
The bit of code in question should be fused away by this rule in `Data/Vector/Generic.hs`:
```
"stream/unstream [Vector]" forall s.
stream (new (New.unstream s)) = s
```
But this isn't happening, I suspect because the dictionary arguments don't match. This was working fine in 7.2.2 which also didn't generate duplicate dictionary bindings.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| 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":"Rule matching regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This shows up in the Quickhull benchmark from the `vector` package. I haven't been able to come up with a smaller example so far. To reproduce, download `vector-0.9.1`, compile `benchmarks/Algo/Quickhull.hs` with `-O2` and look at the output of simplifier phase 2.\r\n\r\nThe bit in question is this (in `hsplit`, in the let-binding for `packed`):\r\n\r\n{{{\r\n (Data.Vector.Generic.stream\r\n @ Data.Vector.Unboxed.Base.Vector\r\n @ ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)\r\n $dVector_a1uD\r\n (Data.Vector.Generic.new\r\n @ Data.Vector.Unboxed.Base.Vector\r\n @ ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)\r\n $dVector_a1nZ\r\n (Data.Vector.Generic.New.unstream\r\n @ Data.Vector.Unboxed.Base.Vector\r\n @ ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)\r\n $dVector_a1nZ\r\n ...\r\n}}}\r\n\r\nThe two dictionaries here are actually equivalent:\r\n\r\n{{{\r\n$dVector_a1nZ\r\n :: Data.Vector.Generic.Base.Vector\r\n Data.Vector.Unboxed.Base.Vector\r\n ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)\r\n$dVector_a1nZ =\r\n Data.Vector.Unboxed.Base.$fVectorVector(,)\r\n @ (GHC.Types.Double, GHC.Types.Double)\r\n @ GHC.Types.Double\r\n $dUnbox_s1ne\r\n Data.Vector.Unboxed.Base.$fUnboxDouble\r\n\r\n$dVector_a1uD\r\n :: Data.Vector.Generic.Base.Vector\r\n Data.Vector.Unboxed.Base.Vector\r\n ((GHC.Types.Double, GHC.Types.Double), GHC.Types.Double)\r\n$dVector_a1uD =\r\n Data.Vector.Unboxed.Base.$fVectorVector(,)\r\n @ (GHC.Types.Double, GHC.Types.Double)\r\n @ GHC.Types.Double\r\n $dUnbox_s1ne\r\n Data.Vector.Unboxed.Base.$fUnboxDouble\r\n}}}\r\n\r\nThe bit of code in question should be fused away by this rule in `Data/Vector/Generic.hs`:\r\n\r\n{{{\r\n\"stream/unstream [Vector]\" forall s.\r\n stream (new (New.unstream s)) = s\r\n}}}\r\n\r\nBut this isn't happening, I suspect because the dictionary arguments don't match. This was working fine in 7.2.2 which also didn't generate duplicate dictionary bindings.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5789Bad link to documentation2019-07-07T18:53:36ZdsfBad link to documentationThe paper "The Design of a Pretty-printing Library" referenced on the front page of the pretty printing package documentation is not accessable: http://www.cs.chalmers.se/\~rjmh/Papers/pretty.ps
<details><summary>Trac metadata</summary>...The paper "The Design of a Pretty-printing Library" referenced on the front page of the pretty printing package documentation is not accessable: http://www.cs.chalmers.se/\~rjmh/Papers/pretty.ps
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/pretty |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bad link to documentation","status":"New","operating_system":"","component":"libraries/pretty","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The paper \"The Design of a Pretty-printing Library\" referenced on the front page of the pretty printing package documentation is not accessable: http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2dtereidterei