GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-11-02T09:27:33Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3828Error in array index2021-11-02T09:27:33ZCBaError in array indexI simply compile ghc-6.12.1 on solaris with ghc 6.8.3.
when compiling `libraries/ghc-prim/./GHC/Types.hs`:
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.12.1 for sparc-sun-solaris2):
Error in array index
```I simply compile ghc-6.12.1 on solaris with ghc 6.8.3.
when compiling `libraries/ghc-prim/./GHC/Types.hs`:
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.12.1 for sparc-sun-solaris2):
Error in array index
```https://gitlab.haskell.org/ghc/ghc/-/issues/3921hsc2hs and Windows line endings on linux2021-11-02T09:27:33Zguesthsc2hs and Windows line endings on linuxThere seems to be a problem when compiling a file under Linux which has Windows line endings and uses \#let 's in the file.
A simple example would be
```
module Main where
#let alignment t = "%lu", (unsigned long)offsetof(struct {char...There seems to be a problem when compiling a file under Linux which has Windows line endings and uses \#let 's in the file.
A simple example would be
```
module Main where
#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
main :: IO ()
main = return ()
```
which does nothing really, but should compile.
this fails under linux (when the file was saved using windows line endings) with the error
```
1.Broken.hsc:4: error: expected identifier or ‘(’ before ‘)’ token
2.compiling Broken_hsc_make.c failed
```
looking at the generated .c file
```
4.#include "/usr/lib/ghc-6.12.1/template-hsc.h"
5.#line 3 "Broken.hsc"
6.#define hsc_alignment(t ) printf ( "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
7.);
8. <truncated>
```
on line 6 the closing ");" was pushed to a new line, 7, but this causes the define to end unexpectedly and cauzes the syntax error mention above. This is presumably because only the "\\n" and the "\\r" are left in there.
also the generated code contains a mixture of both endings, which is no problem for ghc and gcc but might be for some editors:
```
18. fputs ("\r\n"
19. "", stdout);
20. fputs ("\n"
21. "", stdout);
```https://gitlab.haskell.org/ghc/ghc/-/issues/3938Data growth issue in System.Timeout2021-11-02T09:27:32ZleimyData growth issue in System.Timeout(This bug is lhs)
The following seemingly simple code causes infinite data growth and resource exhaustion when the code for System.Timeout does not immediately appear to have a bug with respect to resource utilization.
> module Main wh...(This bug is lhs)
The following seemingly simple code causes infinite data growth and resource exhaustion when the code for System.Timeout does not immediately appear to have a bug with respect to resource utilization.
> module Main where
> import System.Timeout
> import Control.Monad
> timeoutval :: Int
> timeoutval = 12 \* 10 \^ 6 -- 12 seconds
> doit :: IO (Maybe ())
> doit = timeout (-1) $ return ()
> main :: IO ()
> main = forever $ return ()
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data growth issue in System.Timeout","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(This bug is lhs)\r\n\r\nThe following seemingly simple code causes infinite data growth and resource exhaustion when the code for System.Timeout does not immediately appear to have a bug with respect to resource utilization.\r\n\r\n> module Main where\r\n\r\n> import System.Timeout\r\n> import Control.Monad\r\n\r\n> timeoutval :: Int\r\n> timeoutval = 12 * 10 ^ 6 -- 12 seconds\r\n\r\n> doit :: IO (Maybe ())\r\n> doit = timeout (-1) $ return ()\r\n\r\n\r\n> main :: IO ()\r\n> main = forever $ return ()\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3988Spelling correction in LANGUAGE pragmas2021-11-02T09:27:32ZbatterseapowerSpelling correction in LANGUAGE pragmasSomewhat in the spirit of my perenially-ignored #2442 ticket:
```
{-# LANGUAGE ExistientialQuantification #-}
```
Should results in:
```
readFail046.hs:1:14:
Unsupported extension: ExistientialQuantification
Perhaps you meant ...Somewhat in the spirit of my perenially-ignored #2442 ticket:
```
{-# LANGUAGE ExistientialQuantification #-}
```
Should results in:
```
readFail046.hs:1:14:
Unsupported extension: ExistientialQuantification
Perhaps you meant `ExistentialQuantification' or `NoExistentialQuantification'
```
Because I always say RecordWildCards instead of RecordWildcards, and can't remember how to spell "existential" :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Spelling correction in LANGUAGE pragmas","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Somewhat in the spirit of my perenially-ignored #2442 ticket:\r\n\r\n{{{\r\n{-# LANGUAGE ExistientialQuantification #-}\r\n}}}\r\n\r\nShould results in:\r\n\r\n{{{\r\nreadFail046.hs:1:14:\r\n Unsupported extension: ExistientialQuantification\r\n Perhaps you meant `ExistentialQuantification' or `NoExistentialQuantification'\r\n}}}\r\n\r\nBecause I always say RecordWildCards instead of RecordWildcards, and can't remember how to spell \"existential\" :-)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3996bug in GHC when compiling HOC (SVN revision 413)2021-11-02T09:27:32Zandrewebug in GHC when compiling HOC (SVN revision 413)I'm trying to compile the Haskell Cocoa binding HOC on Mac OS X 10.6 (Snow Leopard) with GHC 6.10.4. The computer is a MacBook with Intel CPU.
Steps to reproduce:
```
1. svn checkout http://hoc.googlecode.com/svn/trunk/ hoc-read-only
2...I'm trying to compile the Haskell Cocoa binding HOC on Mac OS X 10.6 (Snow Leopard) with GHC 6.10.4. The computer is a MacBook with Intel CPU.
Steps to reproduce:
```
1. svn checkout http://hoc.googlecode.com/svn/trunk/ hoc-read-only
2. cd hoc-read-only
3. runhaskell Setup.hs --user configure
4. runhaskell Setup.hs build
```
A "GHC panic" error occurs. The output is as follows:
```
Setup.hs:1:0:
Warning: In the use of `defaultUserHooks'
(imported from Distribution.Simple):
Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2
compatibility in which case you must stick with defaultUserHooks"
Compiling HOC_cbits...
Preprocessing library HOC-1.0...
Preprocessing executables for HOC-1.0...
Building HOC-1.0...
[ 1 of 31] Compiling HOC.THDebug ( HOC/HOC/THDebug.hs, dist/build/HOC/THDebug.o )
[ 2 of 31] Compiling HOC.Unicode ( HOC/HOC/Unicode.hs, dist/build/HOC/Unicode.o )
[ 3 of 31] Compiling HOC.TH ( HOC/HOC/TH.hs, dist/build/HOC/TH.o )
[ 4 of 31] Compiling HOC.FFICallInterface ( HOC/HOC/FFICallInterface.hs, dist/build/HOC/FFICallInterface.o )
[ 5 of 31] Compiling HOC.Dyld ( HOC/HOC/Dyld.hs, dist/build/HOC/Dyld.o )
[ 6 of 31] Compiling HOC.Base ( HOC/HOC/Base.hs, dist/build/HOC/Base.o )
[ 7 of 31] Compiling HOC.Arguments ( HOC/HOC/Arguments.hs, dist/build/HOC/Arguments.o )
[ 8 of 31] Compiling HOC.ID ( HOC/HOC/ID.hs, dist/build/HOC/ID.o )
[ 9 of 31] Compiling HOC.CannedCIFs ( HOC/HOC/CannedCIFs.hs, dist/build/HOC/CannedCIFs.o )
[10 of 31] Compiling HOC.NewClass ( HOC/HOC/NewClass.hs, dist/build/HOC/NewClass.o )
[11 of 31] Compiling HOC.StdArgumentTypes ( HOC/HOC/StdArgumentTypes.hs, dist/build/HOC/StdArgumentTypes.o )
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.1 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package parsec-3.1.0 ... linking ... done.
Loading package base-3.0.3.1 ... linking ... done.
Loading package fgl-5.4.2.2 ... linking ... done.
Loading package filepath-1.1.0.2 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.2 ... linking ... done.
Loading package unix-2.3.2.0 ... linking ... done.
Loading package directory-1.0.0.3 ... linking ... done.
Loading package HUnit-1.2.0.3 ... linking ... done.
Loading object (static) dist/build/HOC_cbits.o ... ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for x86_64-apple-darwin):
loadObj: failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4040Eq instance for Data.Data.DataType2021-11-02T09:27:32ZEelis-Eq instance for Data.Data.DataTypeThe DataType data type in Data.Data currently does not derive an Eq instance, even though the types of both of its fields *do* have Eq instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -...The DataType data type in Data.Data currently does not derive an Eq instance, even though the types of both of its fields *do* have Eq instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Eq instance for Data.Data.DataType","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":["syb"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The DataType data type in Data.Data currently does not derive an Eq instance, even though the types of both of its fields ''do'' have Eq instances.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4208ghci/Linker.lhs space leaks2021-11-02T09:27:32ZToRAghci/Linker.lhs space leaksLots of repeated calls to getHValue in ghci/Linker.lhs will cause a thunk to grow (THUNK_2_0 according to -hT). Calling showLinkerState
after each getHValue (in an attempt to force it) shows PersistentLinkerState grows in size quite rapi...Lots of repeated calls to getHValue in ghci/Linker.lhs will cause a thunk to grow (THUNK_2_0 according to -hT). Calling showLinkerState
after each getHValue (in an attempt to force it) shows PersistentLinkerState grows in size quite rapidly.
Possibly related: #4029
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci/Linker.lhs space leaks","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Lots of repeated calls to getHValue in ghci/Linker.lhs will cause a thunk to grow (THUNK_2_0 according to -hT). Calling showLinkerState\r\nafter each getHValue (in an attempt to force it) shows PersistentLinkerState grows in size quite rapidly.\r\n\r\nPossibly related: #4029","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4280Proposal: Performance improvements for Data.Set2021-11-02T09:27:32ZtibbeProposal: Performance improvements for Data.SetFollowing on from ticket #4277 here is a similar patch for `Data.Set`.
This proposal provides a patch that improves performance for many parts of the API. Three standard techniques are applied to the code:
- Worker/Wrapper transformati...Following on from ticket #4277 here is a similar patch for `Data.Set`.
This proposal provides a patch that improves performance for many parts of the API. Three standard techniques are applied to the code:
- Worker/Wrapper transformations of recursive functions with constant arguments (aka. the static argument transformation).
- Explicit inlining of wrapper functions.
- Explicit strictness of keys to functions.
Three complementary, but orthogonal patches are provided.
- Add a testsuite, with [coverage data](http://johantibell.com/files/containers/set/hpc_index.html) (currently 51% of top level functions, and all core functions).
- Add a micro-benchmark suite based on Criterion, for empirical evidence of improvements to each function.
- The optimization patch itself.
All 3 patches should be applied, under this proposal.
The [benchmark results](http://spreadsheets.google.com/pub?key=0AurLfcdFg73_dGZKN1hONFdyVlFudTh2a3BuSTc4NXc&hl=en&gid=1) are relatively clear:
32% faster on OS X 10.5.8 on 2 GHz Core 2 Duo
\[\[Image(https://spreadsheets.google.com/oimg?key=0AurLfcdFg73_dGZKN1hONFdyVlFudTh2a3BuSTc4NXc&oid=2&zx=yh9l2q-h6cvi1)\]\]
The consideration period is 3 weeks (before ICFP).
Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Performance improvements for Data.Set","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Following on from ticket #4277 here is a similar patch for `Data.Set`.\r\n\r\nThis proposal provides a patch that improves performance for many parts of the API. Three standard techniques are applied to the code:\r\n\r\n * Worker/Wrapper transformations of recursive functions with constant arguments (aka. the static argument transformation).\r\n * Explicit inlining of wrapper functions.\r\n * Explicit strictness of keys to functions.\r\n\r\nThree complementary, but orthogonal patches are provided.\r\n\r\n * Add a testsuite, with [http://johantibell.com/files/containers/set/hpc_index.html coverage data] (currently 51% of top level functions, and all core functions).\r\n * Add a micro-benchmark suite based on Criterion, for empirical evidence of improvements to each function.\r\n * The optimization patch itself.\r\n\r\nAll 3 patches should be applied, under this proposal.\r\n\r\nThe [http://spreadsheets.google.com/pub?key=0AurLfcdFg73_dGZKN1hONFdyVlFudTh2a3BuSTc4NXc&hl=en&gid=1 benchmark results] are relatively clear:\r\n\r\n32% faster on OS X 10.5.8 on 2 GHz Core 2 Duo\r\n\r\n[[Image(https://spreadsheets.google.com/oimg?key=0AurLfcdFg73_dGZKN1hONFdyVlFudTh2a3BuSTc4NXc&oid=2&zx=yh9l2q-h6cvi1)]]\r\n\r\nThe consideration period is 3 weeks (before ICFP).\r\n\r\nWork carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4335fromRational broken for Ratio a2021-11-02T09:27:32Zdaniel.is.fischerfromRational broken for Ratio aThe `Fractional` instance for `Ratio a` in GHC.Real defines
```
fromRational (x:%y) = fromInteger x :% fromInteger y
```
For fixed-width Integral types, that produces invalid results:
```
Prelude Data.Ratio> fromRational (1 % 2^3...The `Fractional` instance for `Ratio a` in GHC.Real defines
```
fromRational (x:%y) = fromInteger x :% fromInteger y
```
For fixed-width Integral types, that produces invalid results:
```
Prelude Data.Ratio> fromRational (1 % 2^32) :: Ratio Int
1 % 0
Prelude Data.Ratio> fromRational (3 % (2^32+9)) :: Ratio Int
3 % 9
```
Via `toRational`, these can be ported back to `Rational`.
`Ratio a` is generally broken for fixed-width types:
```
Prelude Data.Ratio> 1 % (minBound :: Int)
(-1) % (-2147483648)
```
but the particular brokenness of `fromRational` can be alleviated by reducing:
```
fromRational (x:%y) = fromInteger x % fromInteger y
{-# RULES
"fromRational/id" fromRational = id :: Rational -> Rational
#-}
```
I think it's better to throw a divide by zero error than to produce invalid results here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| 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":"fromRational broken for Ratio a","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `Fractional` instance for `Ratio a` in GHC.Real defines\r\n{{{\r\n fromRational (x:%y) = fromInteger x :% fromInteger y\r\n}}}\r\nFor fixed-width Integral types, that produces invalid results:\r\n{{{\r\nPrelude Data.Ratio> fromRational (1 % 2^32) :: Ratio Int\r\n1 % 0\r\nPrelude Data.Ratio> fromRational (3 % (2^32+9)) :: Ratio Int\r\n3 % 9\r\n}}}\r\nVia `toRational`, these can be ported back to `Rational`.\r\n\r\n`Ratio a` is generally broken for fixed-width types:\r\n{{{\r\nPrelude Data.Ratio> 1 % (minBound :: Int)\r\n(-1) % (-2147483648)\r\n}}}\r\nbut the particular brokenness of `fromRational` can be alleviated by reducing:\r\n{{{\r\n fromRational (x:%y) = fromInteger x % fromInteger y\r\n\r\n{-# RULES\r\n\"fromRational/id\" fromRational = id :: Rational -> Rational\r\n #-}\r\n}}}\r\nI think it's better to throw a divide by zero error than to produce invalid results here.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4394IPRun failure2021-11-02T09:27:32ZSimon MarlowIPRun failuretypecheck/should_run/IPRun is currently failing all ways:
```
=====> IPRun(normal) 1973 of 2622 [0, 24, 0]
cd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-re...typecheck/should_run/IPRun is currently failing all ways:
```
=====> IPRun(normal) 1973 of 2622 [0, 24, 0]
cd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o IPRun IPRun.hs >IPRun.comp.stderr 2>&1
Compile failed (status 256) errors were:
[1 of 1] Compiling Main ( IPRun.hs, IPRun.o )
IPRun.hs:13:18:
Ambiguous type variable `a' in the constraint:
(Num a) arising from the literal `5'
Probable fix: add a type signature that fixes these type variable(s)
In the expression: 5
In the expression: let ?x = 5 in \ () -> ?x
In an equation for `f2': f2 () = let ?x = 5 in \ () -> ?x
IPRun.hs:24:13:
Ambiguous type variable `a1' in the constraint:
(Show a1) arising from a use of `print'
Probable fix: add a type signature that fixes these type variable(s)
In a stmt of a 'do' expression: print (f2 () ())
In the expression:
do { print (f0 ());
print (f1 ());
print (f2 () ());
print (f3 ()) }
In the expression:
let ?x = 0
in
do { print (f0 ());
print (f1 ());
print (f2 () ());
.... }
*** unexpected failure for IPRun(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"IPRun failure","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"typecheck/should_run/IPRun is currently failing all ways:\r\n\r\n{{{\r\n=====> IPRun(normal) 1973 of 2622 [0, 24, 0]\r\ncd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o IPRun IPRun.hs >IPRun.comp.stderr 2>&1\r\nCompile failed (status 256) errors were:\r\n[1 of 1] Compiling Main ( IPRun.hs, IPRun.o )\r\n\r\nIPRun.hs:13:18:\r\n Ambiguous type variable `a' in the constraint:\r\n (Num a) arising from the literal `5'\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n In the expression: 5\r\n In the expression: let ?x = 5 in \\ () -> ?x\r\n In an equation for `f2': f2 () = let ?x = 5 in \\ () -> ?x\r\n\r\nIPRun.hs:24:13:\r\n Ambiguous type variable `a1' in the constraint:\r\n (Show a1) arising from a use of `print'\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n In a stmt of a 'do' expression: print (f2 () ())\r\n In the expression:\r\n do { print (f0 ());\r\n print (f1 ());\r\n print (f2 () ());\r\n print (f3 ()) }\r\n In the expression:\r\n let ?x = 0\r\n in\r\n do { print (f0 ());\r\n print (f1 ());\r\n print (f2 () ());\r\n .... }\r\n\r\n*** unexpected failure for IPRun(normal)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4834Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)2021-11-02T09:27:32ZgidynImplement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminate...The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -\> Applicative instance declarations.
The proposal is detailed in [the wiki](http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal), along with an example of a legacy module to provide some backwards-compatibility.
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"New Functor => Applicative => Monad Hierarchy","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -> Applicative instance declarations.\r\n\r\nThe proposal is detailed in [http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal the wiki], along with an example of a legacy module to provide some backwards-compatibility. ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5036ghc bug: urk! lookup local fingerprint2021-11-02T09:27:32Zguestghc bug: urk! lookup local fingerprint```
┌─(~/.cabal/packages/hackage.haskell.org/graphalyze/Graphalyze)───────────────────────────────────────────────────────────────────────────────────(pts/16@backup)─┐
cabal clean
cleaning...
┌─(~/.cabal/packages/hackage.haskell.org/grap...```
┌─(~/.cabal/packages/hackage.haskell.org/graphalyze/Graphalyze)───────────────────────────────────────────────────────────────────────────────────(pts/16@backup)─┐
cabal clean
cleaning...
┌─(~/.cabal/packages/hackage.haskell.org/graphalyze/Graphalyze)───────────────────────────────────────────────────────────────────────────────────(pts/16@backup)─┐
cabal install
Resolving dependencies...
Configuring Graphalyze-0.11.0.0...
Preprocessing library Graphalyze-0.11.0.0...
Building Graphalyze-0.11.0.0...
[ 1 of 12] Compiling Paths_Graphalyze ( dist/build/autogen/Paths_Graphalyze.hs, dist/build/Paths_Graphalyze.o )
Implicit import declaration:
Warning: In the use of `catch'
(imported from Prelude, but defined in System.IO.Error):
Deprecated: "Please use the new exceptions variant, Control.Exception.catch"
[ 2 of 12] Compiling Data.Graph.Analysis.Internal ( Data/Graph/Analysis/Internal.hs, dist/build/Data/Graph/Analysis/Internal.o )
[ 3 of 12] Compiling Data.Graph.Analysis.Reporting ( Data/Graph/Analysis/Reporting.hs, dist/build/Data/Graph/Analysis/Reporting.o )
[ 4 of 12] Compiling Data.Graph.Analysis.Reporting.Pandoc ( Data/Graph/Analysis/Reporting/Pandoc.hs, dist/build/Data/Graph/Analysis/Reporting/Pandoc.o )
[ 5 of 12] Compiling Data.Graph.Analysis.Types ( Data/Graph/Analysis/Types.hs, dist/build/Data/Graph/Analysis/Types.o )
[ 6 of 12] Compiling Data.Graph.Analysis.Utils ( Data/Graph/Analysis/Utils.hs, dist/build/Data/Graph/Analysis/Utils.o )
[ 7 of 12] Compiling Data.Graph.Analysis.Visualisation ( Data/Graph/Analysis/Visualisation.hs, dist/build/Data/Graph/Analysis/Visualisation.o )
[ 8 of 12] Compiling Data.Graph.Analysis.Algorithms.Common ( Data/Graph/Analysis/Algorithms/Common.hs, dist/build/Data/Graph/Analysis/Algorithms/Common.o )
Data/Graph/Analysis/Algorithms/Common.hs:40:1:
Warning: The import of `Data.Graph.Inductive.Query.DFS' is redundant
except perhaps to import instances from `Data.Graph.Inductive.Query.DFS'
To import instances alone, use: import Data.Graph.Inductive.Query.DFS()
[ 9 of 12] Compiling Data.Graph.Analysis.Algorithms.Directed ( Data/Graph/Analysis/Algorithms/Directed.hs, dist/build/Data/Graph/Analysis/Algorithms/Directed.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.1.20110209 for i386-unknown-linux):
urk! lookup local fingerprint
Graphalyze-0.11.0.0:Data.Graph.Analysis.Algorithms.Directed.$slookup1{v ruPI}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
Graphalyze-0.11.0.0 failed during the building phase. The exception was:
ExitFailure 1
```7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5126Splicing a type into a signature decl within a decl quotation panics with "mk...2021-11-02T09:27:32ZFSaladSplicing a type into a signature decl within a decl quotation panics with "mkUsageInfo: internal name? x2{v a2pX}"Hello,
trying to compile the attached file gives:
```
[1 of 1] Compiling THUtil ( THUtil.hs, THUtil.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-linux):
mkUsageInfo: internal name?...Hello,
trying to compile the attached file gives:
```
[1 of 1] Compiling THUtil ( THUtil.hs, THUtil.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-linux):
mkUsageInfo: internal name? x2{v a1Jh}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The 'impossible' happened: \"mkUsageInfo: internal name? x2{v a2pX}\"","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["quotation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\ntrying to compile the attached file gives:\r\n\r\n{{{\r\n[1 of 1] Compiling THUtil ( THUtil.hs, THUtil.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.3 for i386-unknown-linux):\r\n mkUsageInfo: internal name? x2{v a1Jh}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5175UTCTime serialization not idempotent2021-11-02T09:27:29ZwarrenUTCTime serialization not idempotentdecode . encode is not idempotent for UTCTime:
```
import Data.Time
import Data.Binary
test = do
t <- getCurrentTime
putStrLn $ "time: " ++ show t
let b = encode t
t' = decode b :: UTCTime
putStrLn $ " t': " ++ show t'
`...decode . encode is not idempotent for UTCTime:
```
import Data.Time
import Data.Binary
test = do
t <- getCurrentTime
putStrLn $ "time: " ++ show t
let b = encode t
t' = decode b :: UTCTime
putStrLn $ " t': " ++ show t'
```
Running this code yields:
```
time: 2011-05-06 18:50:40.972389 UTC
t': 2011-05-06 00:00:00.001148625728 UTC
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"UTCTime serialization not idempotent","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"decode . encode is not idempotent for UTCTime:\r\n\r\n{{{\r\nimport Data.Time\r\nimport Data.Binary\r\n\r\ntest = do\r\n t <- getCurrentTime\r\n putStrLn $ \"time: \" ++ show t\r\n let b = encode t\r\n t' = decode b :: UTCTime\r\n putStrLn $ \" t': \" ++ show t'\r\n}}}\r\n\r\nRunning this code yields:\r\n\r\n{{{\r\ntime: 2011-05-06 18:50:40.972389 UTC\r\n t': 2011-05-06 00:00:00.001148625728 UTC\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5243ghc --make and ghci misses dependencies with explicit braces2021-11-02T09:27:29ZSimon Peyton Jonesghc --make and ghci misses dependencies with explicit bracesKarl Crary tripped over this deeply strange case:
```
Bar.hs
module Bar where
bar = True
Main.hs
{ import Bar; main = print bar }
```
Notice that `Main.hs` is missing its "`module Main where`" part, but has explicit braces an...Karl Crary tripped over this deeply strange case:
```
Bar.hs
module Bar where
bar = True
Main.hs
{ import Bar; main = print bar }
```
Notice that `Main.hs` is missing its "`module Main where`" part, but has explicit braces and semicolons. The BNF in the language standard says that is fine.
If you compile them one at a time all is well:
```
ghc -c Bar.hs
ghc -c Main.hs
```
But if you use `--make` it breaks:
```
simonpj@cam-04-unx:~/tmp$ ghc --make Main -ddump-parsed -ddump-rn
[1 of 1] Compiling Main ( Main.hs, Main.o )
==================== Parser ====================
import Bar
main = print foo
Main.hs:1:29: Not in scope: `foo'
```
Bizarre, eh? This is ghc 7.0.3. It's as if `--make` somehow ignores the import of `Bar`, even though it is parsed just fine.
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | crary@cs.cmu.edu |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc --make and ghci misses dependencies with explicit braces","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["crary@cs.cmu.edu"],"type":"Bug","description":"Karl Crary tripped over this deeply strange case:\r\n{{{\r\nBar.hs\r\n module Bar where\r\n bar = True\r\n\r\nMain.hs\r\n { import Bar; main = print bar }\r\n}}}\r\nNotice that `Main.hs` is missing its \"`module Main where`\" part, but has explicit braces and semicolons. The BNF in the language standard says that is fine.\r\n\r\nIf you compile them one at a time all is well:\r\n{{{\r\nghc -c Bar.hs\r\nghc -c Main.hs \r\n}}}\r\nBut if you use `--make` it breaks:\r\n{{{\r\nsimonpj@cam-04-unx:~/tmp$ ghc --make Main -ddump-parsed -ddump-rn\r\n[1 of 1] Compiling Main ( Main.hs, Main.o )\r\n\r\n==================== Parser ====================\r\nimport Bar\r\nmain = print foo\r\n\r\nMain.hs:1:29: Not in scope: `foo'\r\n}}}\r\nBizarre, eh? This is ghc 7.0.3. It's as if `--make` somehow ignores the import of `Bar`, even though it is parsed just fine.\r\n\r\nSimon","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5339Data.Bits instances should use default shift instead of shiftL/shiftR2021-11-02T09:27:29ZliyangData.Bits instances should use default shift instead of shiftL/shiftRThe documentation notes that the second arg of shiftL/shiftR must be positive, yet many definitions of "instance Bits …" rely on the class defaults implementation of shift.
This patch defines shiftL and shiftR explicitly in terms of the...The documentation notes that the second arg of shiftL/shiftR must be positive, yet many definitions of "instance Bits …" rely on the class defaults implementation of shift.
This patch defines shiftL and shiftR explicitly in terms of the corresponding prim ops, while falling back to the class default for shift. This produces the same output for shift, but much more readable core for shiftL and shiftR.
For "shiftR 1 i", contrast
```
case i of _ { I# i# -> case >=# i# 64 of _ {
False -> uncheckedIShiftRA# 1 i#
True -> 0 } }
```
with
```
case i of _ { I# i# -> let { n# = negateInt# i# } in case >=# n# 0 of _ {
False -> let { nn# = negateInt# n# } in case >=# nn# 64 of _ {
False -> uncheckedIShiftRA# 1 nn#
True -> 0 };
True -> case >=# n# 64 of _ {
False -> uncheckedIShiftL# 1 n#
True -> 0 } } }
```
Cheers,
/Liyang
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Bits instances should use default shift instead of shiftL/shiftR","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The documentation notes that the second arg of shiftL/shiftR must be positive, yet many definitions of \"instance Bits …\" rely on the class defaults implementation of shift.\r\n\r\nThis patch defines shiftL and shiftR explicitly in terms of the corresponding prim ops, while falling back to the class default for shift. This produces the same output for shift, but much more readable core for shiftL and shiftR.\r\n\r\nFor \"shiftR 1 i\", contrast\r\n{{{\r\ncase i of _ { I# i# -> case >=# i# 64 of _ {\r\n False -> uncheckedIShiftRA# 1 i#\r\n True -> 0 } }\r\n}}}\r\nwith\r\n{{{\r\ncase i of _ { I# i# -> let { n# = negateInt# i# } in case >=# n# 0 of _ {\r\n False -> let { nn# = negateInt# n# } in case >=# nn# 64 of _ {\r\n False -> uncheckedIShiftRA# 1 nn#\r\n True -> 0 };\r\n True -> case >=# n# 64 of _ {\r\n False -> uncheckedIShiftL# 1 n#\r\n True -> 0 } } }\r\n}}}\r\n\r\nCheers,\r\n\r\n/Liyang","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5748ghci segfault on OS X after dlsym failed lookup2021-11-02T09:27:29Zgwright@antiope.comghci segfault on OS X after dlsym failed lookupI've had repeatable segfaults with ghci 7.2.2 (OS X 10.6) and 7.0.4 (OS X 10.7 and 10.6). The immediate cause is a failed lookup of an external symbol in `rts/Linker.c`. The failure is not detected and the NULL value returned is eventual...I've had repeatable segfaults with ghci 7.2.2 (OS X 10.6) and 7.0.4 (OS X 10.7 and 10.6). The immediate cause is a failed lookup of an external symbol in `rts/Linker.c`. The failure is not detected and the NULL value returned is eventually dereferenced, leading to a segfault. The underlying bug is still present in HEAD.
This is what happens:
```
gwright-macbook> ghci -v Test.hs
GHCi, version 7.2.2: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 7.2.2, stage 2 booted by GHC version 7.0.4
Using binary package database: /usr/local/lib/ghc-7.2.2/package.conf.d/package.cache
Using binary package database: /Users/gwright/.ghc/x86_64-darwin-7.2.2/package.conf.d/package.cache
hiding package Cabal-1.12.0 to avoid conflict with later version Cabal-1.13.3
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-14e0c022e5d4efa3a40ab5991f2b2a1b
wired-in package integer-gmp mapped to integer-gmp-0.3.0.0-2e2b0fd56be1a5f60c50913e615691d9
wired-in package base mapped to base-4.4.1.0-5ca60b2acbb66fd59e5f81685cb72740
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.6.0.0-e7db5d1205f362bb792ab7bd5c7bbfae
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -static
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *Test.hs
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Sun Jan 1 18:20:14 EST 2012
ms_mod = main:Main,
ms_textual_imps = [import Prelude,
import Math.Symbolic.Wheeler.TensorUtilities,
import Math.Symbolic.Wheeler.TensorBasics,
import Math.Symbolic.Wheeler.Tensor,
import Math.Symbolic.Wheeler.IO,
import Math.Symbolic.Wheeler.Symbol,
import Math.Symbolic.Wheeler.Numeric,
import Math.Symbolic.Wheeler.Expr,
import Math.Symbolic.Wheeler.Commutativity,
import Math.Symbolic.Wheeler.Canonicalize,
import Math.Symbolic.Wheeler.Basic, import Data.Ratio,
import Data.Maybe]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Test.hs
Created temporary directory: /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( Test.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size of Desugar = 788
*** Simplifier:
Result size of Simplifier iteration=1 = 800
Result size of Simplifier = 788
*** Tidy Core:
Result size of Tidy Core = 788
*** CorePrep:
Result size of CorePrep = 1010
*** ByteCodeGen:
Upsweep completely successful.
*** Deleting temp files:
Deleting: /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.c /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.o
Warning: deleting non-existent /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.c
Warning: deleting non-existent /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.o
Ok, modules loaded: Main.
*Main> x
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package bytestring-0.9.2.0 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package array-0.3.0.3 ... linking ... done.
Loading package deepseq-1.2.0.1 ... linking ... done.
Loading package text-0.11.1.12 ... linking ... done.
Loading package parsec-3.1.2 ... linking ... done.
Loading package uniqueid-0.1.1 ... linking ... done.
Loading package Wheeler-0.1 ... linking ... done.
Segmentation fault
gwright-macbook>
```
The program is trying to display a record type (the variable "x"). The record type has a Show instance associated with it, and that is apparently not being resolved correctly, leading to a NULL dereference and a segfault.
The problem is isolated to OS X as far as I can tell. The code responsible for the error is in the function `relocateSection`:
```
else if(reloc->r_extern)
{
struct nlist *symbol = &nlist[reloc->r_symbolnum];
char *nm = image + symLC->stroff + symbol->n_un.n_strx;
IF_DEBUG(linker, debugBelch("relocateSection: looking up external symbol %s\n", nm));
IF_DEBUG(linker, debugBelch(" : type = %d\n", symbol->n_type));
IF_DEBUG(linker, debugBelch(" : sect = %d\n", symbol->n_sect));
IF_DEBUG(linker, debugBelch(" : desc = %d\n", symbol->n_desc));
IF_DEBUG(linker, debugBelch(" : value = %p\n", (void *)symbol->n_value));
if ((symbol->n_type & N_TYPE) == N_SECT) {
value = relocateAddress(oc, nSections, sections,
symbol->n_value);
IF_DEBUG(linker, debugBelch("relocateSection, defined external symbol %s, relocated address %p\n", nm, (void *)value));
}
else {
value = (uint64_t) lookupSymbol(nm);
IF_DEBUG(linker, debugBelch("relocateSection: external symbol %s, address %p\n", nm, (void *)value));
}
}
```
The returned value from `lookupSymbol` is not checked for failure.
A simple check for NULL and a call to `errorBelch` is all that's needed to fix this. There's another place where the return value from `lookupSymbol` is not checked and it should be fixed similarly.
In a bit more detail, the program "Test.hs" I was loading does some simple tests on a library. I admit to having been sloppy while sorting out the module exports, but the library compiles without warnings when -Wall is set. The library has a top-level module that re-exports the most commonly used symbols, but the test program doesn't use it, importing all of the modules it needs explicitly. Am I doing something that is known to be dangerous?
The failed symbol lookup is
```
lookupSymbol: looking up _Wheelerzm0zi1_MathziSymbolicziWheelerziSimpleSymbol_zdfShowSzuzdcshowsPrec_closure
```
which is the Show instance for a `SimpleSymbol` data type. (The library implements a symbolic algebra DSL.) The symbol is undefined in the object module:
```
gwright-macbook> nm HSWheeler-0.1.o | grep "_Wheelerzm0zi1_MathziSymbolicziWheelerziSimpleSymbol_zdfShowSzuzdcshowsPrec_closure"
U _Wheelerzm0zi1_MathziSymbolicziWheelerziSimpleSymbol_zdfShowSzuzdcshowsPrec_closure
gwright-macbook>
```
so some sort of failure is expected when I try to show something of the `SimpleSymbol` type.
I'm puzzled that the first indication of failure is a segfault, or, after I patch `rts/Linker.c`, an error from deep inside the linker. It seems that there is something else going wrong which ought to generate a warning at least.
I will generate a patch against HEAD to check for the failed symbol lookups; it would be good if it were included in the final 7.4.1.
<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 segfault on OS X after dlsym failed lookup","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've had repeatable segfaults with ghci 7.2.2 (OS X 10.6) and 7.0.4 (OS X 10.7 and 10.6). The immediate cause is a failed lookup of an external symbol in {{{rts/Linker.c}}}. The failure is not detected and the NULL value returned is eventually dereferenced, leading to a segfault. The underlying bug is still present in HEAD.\r\n\r\nThis is what happens:\r\n{{{\r\ngwright-macbook> ghci -v Test.hs\r\nGHCi, version 7.2.2: http://www.haskell.org/ghc/ :? for help\r\nGlasgow Haskell Compiler, Version 7.2.2, stage 2 booted by GHC version 7.0.4\r\nUsing binary package database: /usr/local/lib/ghc-7.2.2/package.conf.d/package.cache\r\nUsing binary package database: /Users/gwright/.ghc/x86_64-darwin-7.2.2/package.conf.d/package.cache\r\nhiding package Cabal-1.12.0 to avoid conflict with later version Cabal-1.13.3\r\nwired-in package ghc-prim mapped to ghc-prim-0.2.0.0-14e0c022e5d4efa3a40ab5991f2b2a1b\r\nwired-in package integer-gmp mapped to integer-gmp-0.3.0.0-2e2b0fd56be1a5f60c50913e615691d9\r\nwired-in package base mapped to base-4.4.1.0-5ca60b2acbb66fd59e5f81685cb72740\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.6.0.0-e7db5d1205f362bb792ab7bd5c7bbfae\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags: -static\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\n*** Chasing dependencies:\r\nChasing modules from: \r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep []\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Chasing dependencies:\r\nChasing modules from: *Test.hs\r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Sun Jan 1 18:20:14 EST 2012\r\n ms_mod = main:Main,\r\n ms_textual_imps = [import Prelude,\r\n import Math.Symbolic.Wheeler.TensorUtilities,\r\n import Math.Symbolic.Wheeler.TensorBasics,\r\n import Math.Symbolic.Wheeler.Tensor,\r\n import Math.Symbolic.Wheeler.IO,\r\n import Math.Symbolic.Wheeler.Symbol,\r\n import Math.Symbolic.Wheeler.Numeric,\r\n import Math.Symbolic.Wheeler.Expr,\r\n import Math.Symbolic.Wheeler.Commutativity,\r\n import Math.Symbolic.Wheeler.Canonicalize,\r\n import Math.Symbolic.Wheeler.Basic, import Data.Ratio,\r\n import Data.Maybe]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting: \r\ncompile: input file Test.hs\r\nCreated temporary directory: /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( Test.hs, interpreted )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\nResult size of Desugar = 788\r\n*** Simplifier:\r\nResult size of Simplifier iteration=1 = 800\r\nResult size of Simplifier = 788\r\n*** Tidy Core:\r\nResult size of Tidy Core = 788\r\n*** CorePrep:\r\nResult size of CorePrep = 1010\r\n*** ByteCodeGen:\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.c /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.o\r\nWarning: deleting non-existent /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.c\r\nWarning: deleting non-existent /var/folders/4j/4jmo0VgVHgu2WNrlXKFTB++++TI/-Tmp-/ghc61560_1/ghc61560_0.o\r\nOk, modules loaded: Main.\r\n*Main> x\r\n*** Parser:\r\n*** Desugar:\r\n*** Simplify:\r\n*** CorePrep:\r\n*** ByteCodeGen:\r\nLoading package bytestring-0.9.2.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 array-0.3.0.3 ... linking ... done.\r\nLoading package deepseq-1.2.0.1 ... linking ... done.\r\nLoading package text-0.11.1.12 ... linking ... done.\r\nLoading package parsec-3.1.2 ... linking ... done.\r\nLoading package uniqueid-0.1.1 ... linking ... done.\r\nLoading package Wheeler-0.1 ... linking ... done.\r\nSegmentation fault\r\ngwright-macbook> \r\n}}}\r\n\r\nThe program is trying to display a record type (the variable \"x\"). The record type has a Show instance associated with it, and that is apparently not being resolved correctly, leading to a NULL dereference and a segfault.\r\n\r\nThe problem is isolated to OS X as far as I can tell. The code responsible for the error is in the function {{{relocateSection}}}:\r\n\r\n{{{\r\n else if(reloc->r_extern)\r\n {\r\n struct nlist *symbol = &nlist[reloc->r_symbolnum];\r\n char *nm = image + symLC->stroff + symbol->n_un.n_strx;\r\n\r\n IF_DEBUG(linker, debugBelch(\"relocateSection: looking up external symbol %s\\n\", nm));\r\n IF_DEBUG(linker, debugBelch(\" : type = %d\\n\", symbol->n_type));\r\n IF_DEBUG(linker, debugBelch(\" : sect = %d\\n\", symbol->n_sect));\r\n IF_DEBUG(linker, debugBelch(\" : desc = %d\\n\", symbol->n_desc));\r\n IF_DEBUG(linker, debugBelch(\" : value = %p\\n\", (void *)symbol->n_value));\r\n if ((symbol->n_type & N_TYPE) == N_SECT) {\r\n value = relocateAddress(oc, nSections, sections,\r\n symbol->n_value);\r\n IF_DEBUG(linker, debugBelch(\"relocateSection, defined external symbol %s, relocated address %p\\n\", nm, (void *)value));\r\n }\r\n else {\r\n value = (uint64_t) lookupSymbol(nm);\r\n IF_DEBUG(linker, debugBelch(\"relocateSection: external symbol %s, address %p\\n\", nm, (void *)value));\r\n }\r\n }\r\n}}}\r\n\r\nThe returned value from {{{lookupSymbol}}} is not checked for failure.\r\nA simple check for NULL and a call to {{{errorBelch}}} is all that's needed to fix this. There's another place where the return value from {{{lookupSymbol}}} is not checked and it should be fixed similarly.\r\n\r\nIn a bit more detail, the program \"Test.hs\" I was loading does some simple tests on a library. I admit to having been sloppy while sorting out the module exports, but the library compiles without warnings when -Wall is set. The library has a top-level module that re-exports the most commonly used symbols, but the test program doesn't use it, importing all of the modules it needs explicitly. Am I doing something that is known to be dangerous?\r\n\r\nThe failed symbol lookup is \r\n\r\n{{{\r\nlookupSymbol: looking up _Wheelerzm0zi1_MathziSymbolicziWheelerziSimpleSymbol_zdfShowSzuzdcshowsPrec_closure\r\n}}}\r\n\r\nwhich is the Show instance for a {{{SimpleSymbol}}} data type. (The library implements a symbolic algebra DSL.) The symbol is undefined in the object module:\r\n\r\n{{{\r\ngwright-macbook> nm HSWheeler-0.1.o | grep \"_Wheelerzm0zi1_MathziSymbolicziWheelerziSimpleSymbol_zdfShowSzuzdcshowsPrec_closure\"\r\n U _Wheelerzm0zi1_MathziSymbolicziWheelerziSimpleSymbol_zdfShowSzuzdcshowsPrec_closure\r\ngwright-macbook> \r\n}}}\r\n\r\nso some sort of failure is expected when I try to show something of the {{{SimpleSymbol}}} type.\r\n\r\nI'm puzzled that the first indication of failure is a segfault, or, after I patch {{{rts/Linker.c}}}, an error from deep inside the linker. It seems that there is something else going wrong which ought to generate a warning at least.\r\n\r\nI will generate a patch against HEAD to check for the failed symbol lookups; it would be good if it were included in the final 7.4.1.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/5749GHC 7.0.4 Performance Regression (Possibly Vector)2021-11-02T09:27:29ZsanketrGHC 7.0.4 Performance Regression (Possibly Vector)I have noticed \~100% performance degradation for my code when I switched from 6.12.3 to 7.0.4. This might be related to vector performance ticket [5623](http://hackage.haskell.org/trac/ghc/ticket/5623) but I noticed it was filed for per...I have noticed \~100% performance degradation for my code when I switched from 6.12.3 to 7.0.4. This might be related to vector performance ticket [5623](http://hackage.haskell.org/trac/ghc/ticket/5623) but I noticed it was filed for performance regression of 7.2.1 relative to 7.0.4, and 6.12.1 vs 7.0.4 performance was reported as ok. So, I am filing it as new bug report.
I am attaching an edited version of my code below which reproduces the issue. It is from actual production code which is used for db driver. Relevant performance benchmarks (\~95% degradation):
**GHC 6.12.3 MUT Time:** 0.48s
**GHC 7.0.4 MUT Time:** 0.95s
In actual code, performance degrades by \~100%, from \~1.3s to \~2.6s. So, I can't move from 6.12.3 to 7.0.4 or 7.4+ if I want to keep the performance :(
Code below - the comment block at the end shows how to compile, and reproduce the issue - I will be happy to provide more information to fix the issue:
```
{-# LANGUAGE BangPatterns #-}
import qualified Data.Vector.Storable as SV
import qualified Data.Vector.Storable.Mutable as MSV
import qualified Data.Vector as V
import Foreign (sizeOf)
import Foreign.C.Types (CChar)
import GHC.Int
import System.IO.Unsafe (unsafePerformIO)
import Control.Exception (evaluate)
data Elems = IV {-# UNPACK #-} !(SV.Vector Int32)
| SV {-#UNPACK #-} !Int {-# UNPACK #-} !(SV.Vector CChar) -- Int stores the number of null-terminated C Strings
| T {-# UNPACK #-} !Int {-# UNPACK #-} !(V.Vector Elems) -- Int stores total bytes needed to copy vectors to ByteString
| L {-# UNPACK #-} !(V.Vector Elems) -- General list of elements
deriving (Show)
-- | Function to return total size in bytes taken to store the data from Elems
size :: Elems -> Int
size (IV x) = 6 + (sizeOf (undefined :: Int32)) * (SV.length x)
size (SV _ x) = 6 + (sizeOf (undefined :: CChar)) * (SV.length x)
size (T n _) = n
size (L x) = V.foldl' (\x y -> x + size y) 6 x
{-# INLINE size #-}
fillS :: [[CChar]] -> Elems
fillS x = let (x',y') = createS x
in SV x' y'
{-# INLINE fillS #-}
createS :: [[CChar]] -> (Int, SV.Vector CChar)
createS cl = unsafePerformIO $ do
v <- MSV.new (Prelude.length . Prelude.concat $ cl)
fill v 0 $ Prelude.concat cl
SV.unsafeFreeze v >>= \x -> return (Prelude.length cl,x)
where
fill v _ [] = return ()
fill v i (x:xs) = MSV.unsafeWrite v i x >> fill v (i + 1) xs
{-# INLINE createS #-}
-- | Constructor for T - a db table - we must always build it using this function
fillT :: V.Vector Elems -> Elems
fillT !xs = T (V.foldl' (\x y -> x + size y) 3 xs) xs -- 2 bytes for table header + 1 additional byte for dict type header => 3 bytes additional overhead
{-# INLINE fillT #-}
main = do
let il1 = IV $ SV.enumFromN 1 50000000
il2 = IV $ SV.enumFromN 1 50000000
il3 = IV $ SV.enumFromN 1 50000000
l1 = L (V.fromList [il1,il2,il3])
sl1 = fillS [[97,0],[98,0],[99,0]]
evaluate $ fillT (V.fromList [sl1,l1])
return ()
{-- GHC 6.12.3:
$ ghc -O2 --make test.hs -fforce-recomp -rtsopts -fasm && ./test +RTS -s
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
./test +RTS -s
600,843,536 bytes allocated in the heap
8,336 bytes copied during GC
200,002,504 bytes maximum residency (2 sample(s))
793,936 bytes maximum slop
574 MB total memory in use (9 MB lost due to fragmentation)
Generation 0: 2 collections, 0 parallel, 0.00s, 0.00s elapsed
Generation 1: 2 collections, 0 parallel, 0.00s, 0.00s elapsed
INIT time 0.00s ( 0.00s elapsed)
MUT time 0.48s ( 0.97s elapsed)
GC time 0.00s ( 0.00s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 0.48s ( 0.97s elapsed)
%GC time 0.2% (0.1% elapsed)
Alloc rate 1,259,822,857 bytes per MUT second
Productivity 99.6% of total user, 49.0% of total elapsed
-----
GHC 7.0.4:
$ ghc -O2 --make test.hs -fforce-recomp -rtsopts -fasm && ./test +RTS -s
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
./test +RTS -s
600,836,872 bytes allocated in the heap
7,664 bytes copied during GC
200,002,224 bytes maximum residency (2 sample(s))
794,216 bytes maximum slop
574 MB total memory in use (0 MB lost due to fragmentation)
Generation 0: 2 collections, 0 parallel, 0.00s, 0.00s elapsed
Generation 1: 2 collections, 0 parallel, 0.11s, 0.11s elapsed
INIT time 0.00s ( 0.00s elapsed)
MUT time 0.94s ( 1.01s elapsed)
GC time 0.11s ( 0.11s elapsed)
EXIT time 0.00s ( 0.11s elapsed)
Total time 1.05s ( 1.12s elapsed)
%GC time 10.2% (9.7% elapsed)
Alloc rate 638,055,951 bytes per MUT second
Productivity 89.4% of total user, 83.4% of total elapsed
--}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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 7.0.4 Performance Regression (Possibly Vector)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":["performance,","vector"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have noticed ~100% performance degradation for my code when I switched from 6.12.3 to 7.0.4. This might be related to vector performance ticket [http://hackage.haskell.org/trac/ghc/ticket/5623 5623] but I noticed it was filed for performance regression of 7.2.1 relative to 7.0.4, and 6.12.1 vs 7.0.4 performance was reported as ok. So, I am filing it as new bug report.\r\n\r\nI am attaching an edited version of my code below which reproduces the issue. It is from actual production code which is used for db driver. Relevant performance benchmarks (~95% degradation):\r\n\r\n'''GHC 6.12.3 MUT Time:''' 0.48s\r\n\r\n'''GHC 7.0.4 MUT Time:''' 0.95s\r\n\r\nIn actual code, performance degrades by ~100%, from ~1.3s to ~2.6s. So, I can't move from 6.12.3 to 7.0.4 or 7.4+ if I want to keep the performance :(\r\n\r\nCode below - the comment block at the end shows how to compile, and reproduce the issue - I will be happy to provide more information to fix the issue:\r\n\r\n\r\n{{{\r\n{-# LANGUAGE BangPatterns #-}\r\nimport qualified Data.Vector.Storable as SV\r\nimport qualified Data.Vector.Storable.Mutable as MSV\r\nimport qualified Data.Vector as V\r\nimport Foreign (sizeOf)\r\nimport Foreign.C.Types (CChar)\r\nimport GHC.Int\r\nimport System.IO.Unsafe (unsafePerformIO)\r\nimport Control.Exception (evaluate)\r\n\r\n\r\ndata Elems = IV {-# UNPACK #-} !(SV.Vector Int32)\r\n | SV {-#UNPACK #-} !Int {-# UNPACK #-} !(SV.Vector CChar) -- Int stores the number of null-terminated C Strings\r\n | T {-# UNPACK #-} !Int {-# UNPACK #-} !(V.Vector Elems) -- Int stores total bytes needed to copy vectors to ByteString\r\n | L {-# UNPACK #-} !(V.Vector Elems) -- General list of elements\r\n deriving (Show)\r\n\r\n-- | Function to return total size in bytes taken to store the data from Elems\r\nsize :: Elems -> Int\r\nsize (IV x) = 6 + (sizeOf (undefined :: Int32)) * (SV.length x)\r\nsize (SV _ x) = 6 + (sizeOf (undefined :: CChar)) * (SV.length x)\r\nsize (T n _) = n\r\nsize (L x) = V.foldl' (\\x y -> x + size y) 6 x\r\n{-# INLINE size #-}\r\n\r\nfillS :: [[CChar]] -> Elems\r\nfillS x = let (x',y') = createS x\r\n in SV x' y'\r\n{-# INLINE fillS #-}\r\n\r\ncreateS :: [[CChar]] -> (Int, SV.Vector CChar)\r\ncreateS cl = unsafePerformIO $ do\r\n v <- MSV.new (Prelude.length . Prelude.concat $ cl)\r\n fill v 0 $ Prelude.concat cl\r\n SV.unsafeFreeze v >>= \\x -> return (Prelude.length cl,x)\r\n where\r\n fill v _ [] = return ()\r\n fill v i (x:xs) = MSV.unsafeWrite v i x >> fill v (i + 1) xs\r\n{-# INLINE createS #-}\r\n\r\n-- | Constructor for T - a db table - we must always build it using this function\r\nfillT :: V.Vector Elems -> Elems\r\nfillT !xs = T (V.foldl' (\\x y -> x + size y) 3 xs) xs -- 2 bytes for table header + 1 additional byte for dict type header => 3 bytes additional overhead\r\n{-# INLINE fillT #-}\r\n\r\nmain = do\r\n let il1 = IV $ SV.enumFromN 1 50000000\r\n il2 = IV $ SV.enumFromN 1 50000000\r\n il3 = IV $ SV.enumFromN 1 50000000\r\n l1 = L (V.fromList [il1,il2,il3])\r\n sl1 = fillS [[97,0],[98,0],[99,0]]\r\n evaluate $ fillT (V.fromList [sl1,l1])\r\n return ()\r\n\r\n{-- GHC 6.12.3:\r\n\r\n $ ghc -O2 --make test.hs -fforce-recomp -rtsopts -fasm && ./test +RTS -s\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\n./test +RTS -s\r\n 600,843,536 bytes allocated in the heap\r\n 8,336 bytes copied during GC\r\n 200,002,504 bytes maximum residency (2 sample(s))\r\n 793,936 bytes maximum slop\r\n 574 MB total memory in use (9 MB lost due to fragmentation)\r\n\r\n Generation 0: 2 collections, 0 parallel, 0.00s, 0.00s elapsed\r\n Generation 1: 2 collections, 0 parallel, 0.00s, 0.00s elapsed\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 0.48s ( 0.97s elapsed)\r\n GC time 0.00s ( 0.00s elapsed)\r\n EXIT time 0.00s ( 0.00s elapsed)\r\n Total time 0.48s ( 0.97s elapsed)\r\n\r\n %GC time 0.2% (0.1% elapsed)\r\n\r\n Alloc rate 1,259,822,857 bytes per MUT second\r\n\r\n Productivity 99.6% of total user, 49.0% of total elapsed\r\n\r\n-----\r\nGHC 7.0.4:\r\n\r\n $ ghc -O2 --make test.hs -fforce-recomp -rtsopts -fasm && ./test +RTS -s\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\n./test +RTS -s\r\n 600,836,872 bytes allocated in the heap\r\n 7,664 bytes copied during GC\r\n 200,002,224 bytes maximum residency (2 sample(s))\r\n 794,216 bytes maximum slop\r\n 574 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Generation 0: 2 collections, 0 parallel, 0.00s, 0.00s elapsed\r\n Generation 1: 2 collections, 0 parallel, 0.11s, 0.11s elapsed\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 0.94s ( 1.01s elapsed)\r\n GC time 0.11s ( 0.11s elapsed)\r\n EXIT time 0.00s ( 0.11s elapsed)\r\n Total time 1.05s ( 1.12s elapsed)\r\n\r\n %GC time 10.2% (9.7% elapsed)\r\n\r\n Alloc rate 638,055,951 bytes per MUT second\r\n\r\n Productivity 89.4% of total user, 83.4% of total elapsed\r\n--}\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15547A function `nat2Word# :: KnownNat n => Proxy# n -> Word#`2021-10-29T23:37:39ZChaiTRexA function `nat2Word# :: KnownNat n => Proxy# n -> Word#`It would be nice if there were the function (perhaps in `GHC.Prim`) `nat2Word# :: KnownNat n => Proxy# n -> Word#` that was essentially `(\ W# w# -> w#) . fromInteger . natVal`, except that it produces the `Word#` at compile-time rather ...It would be nice if there were the function (perhaps in `GHC.Prim`) `nat2Word# :: KnownNat n => Proxy# n -> Word#` that was essentially `(\ W# w# -> w#) . fromInteger . natVal`, except that it produces the `Word#` at compile-time rather than runtime and that it works with `Proxy#` (for [its no-runtime-representation, totally-free nature](https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC-Exts.html#t:Proxy-35-)) instead of `Proxy`.
This would enable compile-time computations on `Nat`s to produce a literal `Word#` without any runtime expense at all, which seems nice if you're dealing with primitives *because* you want to avoid runtime expense.
## Motivating example
I'm learning primitive types and type-level arithmetic by making a simple set of fixed-width integer types where the type contains a `Nat` for the number of bits in the fixed-width integer.
Going from the following `Nat`s to their corresponding `Word#`s at compile time even when optimizations are turned off during development would be very nice:
<table><tr><th> `Div (n + 63) 64` \\\\=</th>
<td>the highest index we should try to access via `indexWordArray#` </td></tr>
<tr><th> `Mod (n - 1) 64 + 1` \\\\=</th>
<td>except when `n == 0`, the number of bits actually used in the \\\\ most-significant word </td></tr>
<tr><th> `2^(Mod (n + 63) 64 + 1) - 1` \\\\=</th>
<td>the unsigned integer narrowing bitmask to use on the \\\\ most-significant word </td></tr></table>
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.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":"A function `nat2Word# :: KnownNat n => Proxy# n -> Word#`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be nice if there were the function (perhaps in `GHC.Prim`) `nat2Word# :: KnownNat n => Proxy# n -> Word#` that was essentially `(\\ W# w# -> w#) . fromInteger . natVal`, except that it produces the `Word#` at compile-time rather than runtime and that it works with `Proxy#` (for [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC-Exts.html#t:Proxy-35- its no-runtime-representation, totally-free nature]) instead of `Proxy`.\r\n\r\nThis would enable compile-time computations on `Nat`s to produce a literal `Word#` without any runtime expense at all, which seems nice if you're dealing with primitives ''because'' you want to avoid runtime expense.\r\n\r\n== Motivating example\r\n\r\nI'm learning primitive types and type-level arithmetic by making a simple set of fixed-width integer types where the type contains a `Nat` for the number of bits in the fixed-width integer.\r\n\r\nGoing from the following `Nat`s to their corresponding `Word#`s at compile time even when optimizations are turned off during development would be very nice:\r\n\r\n||= `Div (n + 63) 64` \\\\=||the highest index we should try to access via `indexWordArray#` ||\r\n||= `Mod (n - 1) 64 + 1` \\\\=||except when `n == 0`, the number of bits actually used in the \\\\ most-significant word ||\r\n||= `2^(Mod (n + 63) 64 + 1) - 1` \\\\=||the unsigned integer narrowing bitmask to use on the \\\\ most-significant word ||\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/1650.boot modules interact badly with the ghci debugger2021-10-27T20:50:29Zmnislaih.boot modules interact badly with the ghci debuggerIf a boot module is loaded _after_ its normal counterpart, which can happen, the module ends up with empty modBreaks info, which leads to errors while debugging.
It looks like boot modules take the place of their normal counterparts in t...If a boot module is loaded _after_ its normal counterpart, which can happen, the module ends up with empty modBreaks info, which leads to errors while debugging.
It looks like boot modules take the place of their normal counterparts in the HomePackageTable perhaps?
An example:
```
GHCi, version 6.7.20070826: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :l C
[1 of 4] Compiling B[boot] ( B.hs-boot, interpreted )
[2 of 4] Compiling A ( A.hs, interpreted )
[3 of 4] Compiling B ( B.hs, interpreted )
[4 of 4] Compiling C ( C.hs, interpreted )
Ok, modules loaded: B, B, C, A.
*C> :! touch A.hs
*C> :r
[1 of 4] Compiling B[boot] ( B.hs-boot, interpreted )
[2 of 4] Compiling A ( A.hs, interpreted )
Ok, modules loaded: B, B, C, A.
*C> :break a
Breakpoint 0 activated at A.hs:4:0-8
*C> a ()
Stopped at A.hs:4:0-8
_result :: a = _
3
4 a x = b x
[A.hs:4:0-8] *C> :st
Stopped at A.hs:4:6-8
_result :: () = _
x :: () = ()
3
4 a x = b x
[A.hs:4:6-8] *C> :st
*** Exception: Error in array index
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mnislaih@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":".boot modules interact badly with the ghci debugger","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"Unknown","cc":["mnislaih@gmail.com"],"type":"Bug","description":"If a boot module is loaded _after_ its normal counterpart, which can happen, the module ends up with empty modBreaks info, which leads to errors while debugging.\r\nIt looks like boot modules take the place of their normal counterparts in the HomePackageTable perhaps?\r\nAn example:\r\n\r\n\r\n{{{\r\nGHCi, version 6.7.20070826: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :l C\r\n[1 of 4] Compiling B[boot] ( B.hs-boot, interpreted )\r\n[2 of 4] Compiling A ( A.hs, interpreted )\r\n[3 of 4] Compiling B ( B.hs, interpreted )\r\n[4 of 4] Compiling C ( C.hs, interpreted )\r\nOk, modules loaded: B, B, C, A.\r\n*C> :! touch A.hs\r\n*C> :r\r\n[1 of 4] Compiling B[boot] ( B.hs-boot, interpreted )\r\n[2 of 4] Compiling A ( A.hs, interpreted )\r\nOk, modules loaded: B, B, C, A.\r\n*C> :break a\r\nBreakpoint 0 activated at A.hs:4:0-8\r\n*C> a ()\r\nStopped at A.hs:4:0-8\r\n_result :: a = _\r\n3 \r\n4 a x = b x\r\n[A.hs:4:0-8] *C> :st\r\nStopped at A.hs:4:6-8\r\n_result :: () = _\r\nx :: () = ()\r\n3 \r\n4 a x = b x\r\n[A.hs:4:6-8] *C> :st \r\n*** Exception: Error in array index\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1