GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:05:53Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3011ASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv}2019-07-07T19:05:53ZbatterseapowerASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv}NB: this is NOT AFAIK a duplicate of the previous ticket about the TcMType ASSERT failure. It was observed on a recent HEAD (as of 6th February 2009) while I happened to be using a stage 2 compiler with -DDEBUG on to compile some code I ...NB: this is NOT AFAIK a duplicate of the previous ticket about the TcMType ASSERT failure. It was observed on a recent HEAD (as of 6th February 2009) while I happened to be using a stage 2 compiler with -DDEBUG on to compile some code I was working on.
Error is as follows:
```
$ ./Setup clean && ./Setup configure --with-compiler=/Users/mbolingbroke/Programming/Checkouts/ghc.working/ghc/stage2-inplace/ghc --with-hc-pkg=/Users/mbolingbroke/Programming/Checkouts/ghc.working/ghc/stage2-inplace/ghc-pkg --ghc --global && ./Setup build && dist/build/vector-tests/vector-tests
cleaning...
Configuring vector-tests-0.2...
Preprocessing executables for vector-tests-0.2...
Building vector-tests-0.2...
[1 of 3] Compiling Utilities ( Utilities.hs, dist/build/vector-tests/vector-tests-tmp/Utilities.o )
WARNING: file simplCore/SimplCore.lhs line 545
Simplifier still going after 4 iterations; bailing out. Size = 1398
[2 of 3] Compiling Properties ( Properties.hs, dist/build/vector-tests/vector-tests-tmp/Properties.o )
WARNING: file typecheck/TcTyFuns.lhs line 284
(This warning is harmless; for Simon & Manuel)
[Wanted t_a32G{tv} [tau] :: ghc-prim:GHC.Types.[]{(w) tc 317}
~
v{tv a2S9} [sk]]
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20090204 for i386-apple-darwin):
ASSERT failed! file typecheck/TcMType.lhs line 526 t_a32G{tv} [tau]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Where that code look something like this:
```
do { ASSERTM2( do { details <- readMetaTyVar tyvar; return (isFlexi details) }, ppr tyvar )
; traceTc (text "writeMetaTyVar" <+> ppr tyvar <+> text ":=" <+> ppr ty)
; writeMutVar (metaTvRef tyvar) (Indirect ty) }
```
Full program is attached.
Actually, the program has a type error (as rerunning with a non -DDEBUG build showed):
```
Properties.hs:78:25:
Could not deduce (Data.Vector.Unboxed.IVector [] a)
from the context (Eq a,
Ord a,
Eq (v a),
Ord (v a),
Show a,
Arbitrary a,
Model a a,
Show (v a),
Arbitrary (v a),
Model (v a) [a],
Data.Vector.Unboxed.IVector v a,
Show (v Bool),
Arbitrary (v Bool),
Model (v Bool) [Bool],
Data.Vector.Unboxed.IVector v Bool)
arising from a use of `Data.Vector.Unboxed.length'
at Properties.hs:78:25-32
Possible fix:
add (Data.Vector.Unboxed.IVector [] a) to the context of
the type signature for `testVersusLists'
or add an instance declaration for
(Data.Vector.Unboxed.IVector [] a)
In the first argument of `eq1', namely
`(Data.Vector.Unboxed.length :: v a -> Int)'
In the expression:
(Data.Vector.Unboxed.length :: v a -> Int) `eq1` length
In the definition of `prop_length':
prop_length = (Data.Vector.Unboxed.length :: v a -> Int)
`eq1`
length
Properties.hs:83:25:
No instance for (Data.Vector.Unboxed.IVector [] Bool)
arising from a use of `Data.Vector.Unboxed.and'
at Properties.hs:83:25-29
Possible fix:
add an instance declaration for
(Data.Vector.Unboxed.IVector [] Bool)
In the first argument of `eq1', namely
`(Data.Vector.Unboxed.and :: v Bool -> Bool)'
In the expression:
(Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and
In the definition of `prop_and':
prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and
Properties.hs:95:24:
Could not deduce (Eq ([a] -> [a]))
from the context (Eq a,
Ord a,
Eq (v a),
Ord (v a),
Show a,
Arbitrary a,
Model a a,
Show (v a),
Arbitrary (v a),
Model (v a) [a],
Data.Vector.Unboxed.IVector v a,
Show (v Bool),
Arbitrary (v Bool),
Model (v Bool) [Bool],
Data.Vector.Unboxed.IVector v Bool)
arising from a use of `eq2' at Properties.hs:95:24-86
Possible fix:
add (Eq ([a] -> [a])) to the context of
the type signature for `testVersusLists'
or add an instance declaration for (Eq ([a] -> [a]))
In the expression:
(Data.Vector.Unboxed.zipWith :: (a -> a -> a) -> v a -> v a -> v a)
`eq2`
zipWith
In the definition of `prop_zipWith':
prop_zipWith = (Data.Vector.Unboxed.zipWith ::
(a -> a -> a) -> v a -> v a -> v a)
`eq2`
zipWith
In the definition of `testVersusLists':
testVersusLists _ = [testGroup "Prelude" prelude_tests,
testGroup "Data.List" data_list_tests,
testGroup "Extras" extra_tests]
where
prelude_tests = [testProperty "length" prop_length, ....]
prop_length = (Data.Vector.Unboxed.length :: v a -> Int)
`eq1`
length
prop_null = (Data.Vector.Unboxed.null :: v a -> Bool) `eq1` null
prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and
....
Properties.hs:114:25:
Couldn't match expected type `v' against inferred type `[]'
`v' is a rigid type variable bound by
the type signature for `testVersusLists' at Properties.hs:19:28
In the first argument of `eq2', namely
`(enumFromTo :: a -> a -> v a)'
In the expression: (enumFromTo :: a -> a -> v a) `eq2` enumFromTo
In the definition of `prop_enumFromTo':
prop_enumFromTo = (enumFromTo :: a -> a -> v a) `eq2` enumFromTo
Properties.hs:115:76:
Could not deduce (Enum a)
from the context (Eq a,
Ord a,
Eq (v a),
Ord (v a),
Show a,
Arbitrary a,
Model a a,
Show (v a),
Arbitrary (v a),
Model (v a) [a],
Data.Vector.Unboxed.IVector v a,
Show (v Bool),
Arbitrary (v Bool),
Model (v Bool) [Bool],
Data.Vector.Unboxed.IVector v Bool)
arising from a use of `enumFromThenTo' at Properties.hs:115:76-89
Possible fix:
add (Enum a) to the context of
the type signature for `testVersusLists'
In the second argument of `eq3', namely `enumFromThenTo'
In the expression:
(enumFromThenTo :: a -> a -> a -> v a) `eq3` enumFromThenTo
In the definition of `prop_enumFromThenTo':
prop_enumFromThenTo = (enumFromThenTo :: a -> a -> a -> v a)
`eq3`
enumFromThenTo
Properties.hs:176:16:
Could not deduce (Model [a] [a])
from the context (Eq a,
Ord a,
Eq (v a),
Ord (v a),
Show a,
Arbitrary a,
Model a a,
Show (v a),
Arbitrary (v a),
Model (v a) [a],
Data.Vector.Unboxed.IVector v a,
Show (v Bool),
Arbitrary (v Bool),
Model (v Bool) [Bool],
Data.Vector.Unboxed.IVector v Bool)
arising from a use of `eq2' at Properties.hs:176:16-71
Possible fix:
add (Model [a] [a]) to the context of
the type signature for `testVersusLists'
or add an instance declaration for (Model [a] [a])
In the expression:
(Data.Vector.Unboxed.snoc :: v a -> a -> v a) `eq2` snoc
In the definition of `prop_snoc':
prop_snoc = (Data.Vector.Unboxed.snoc :: v a -> a -> v a)
`eq2`
snoc
In the definition of `testVersusLists':
testVersusLists _ = [testGroup "Prelude" prelude_tests,
testGroup "Data.List" data_list_tests,
testGroup "Extras" extra_tests]
where
prelude_tests = [testProperty "length" prop_length, ....]
prop_length = (Data.Vector.Unboxed.length :: v a -> Int)
`eq1`
length
prop_null = (Data.Vector.Unboxed.null :: v a -> Bool) `eq1` null
prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and
....
```
But we probably still shouldn't get the ASSERT.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv}","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"NB: this is NOT AFAIK a duplicate of the previous ticket about the TcMType ASSERT failure. It was observed on a recent HEAD (as of 6th February 2009) while I happened to be using a stage 2 compiler with -DDEBUG on to compile some code I was working on.\r\n\r\nError is as follows:\r\n{{{\r\n$ ./Setup clean && ./Setup configure --with-compiler=/Users/mbolingbroke/Programming/Checkouts/ghc.working/ghc/stage2-inplace/ghc --with-hc-pkg=/Users/mbolingbroke/Programming/Checkouts/ghc.working/ghc/stage2-inplace/ghc-pkg --ghc --global && ./Setup build && dist/build/vector-tests/vector-tests\r\ncleaning...\r\nConfiguring vector-tests-0.2...\r\nPreprocessing executables for vector-tests-0.2...\r\nBuilding vector-tests-0.2...\r\n[1 of 3] Compiling Utilities ( Utilities.hs, dist/build/vector-tests/vector-tests-tmp/Utilities.o )\r\nWARNING: file simplCore/SimplCore.lhs line 545\r\nSimplifier still going after 4 iterations; bailing out. Size = 1398\r\n\r\n[2 of 3] Compiling Properties ( Properties.hs, dist/build/vector-tests/vector-tests-tmp/Properties.o )\r\nWARNING: file typecheck/TcTyFuns.lhs line 284\r\n(This warning is harmless; for Simon & Manuel)\r\n[Wanted t_a32G{tv} [tau] :: ghc-prim:GHC.Types.[]{(w) tc 317}\r\n ~\r\n v{tv a2S9} [sk]]\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.11.20090204 for i386-apple-darwin):\r\n ASSERT failed! file typecheck/TcMType.lhs line 526 t_a32G{tv} [tau]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nWhere that code look something like this:\r\n\r\n{{{\r\n do\t{ ASSERTM2( do { details <- readMetaTyVar tyvar; return (isFlexi details) }, ppr tyvar )\r\n\t; traceTc (text \"writeMetaTyVar\" <+> ppr tyvar <+> text \":=\" <+> ppr ty)\r\n\t; writeMutVar (metaTvRef tyvar) (Indirect ty) }\r\n}}}\r\n\r\nFull program is attached.\r\n\r\nActually, the program has a type error (as rerunning with a non -DDEBUG build showed):\r\n\r\n{{{\r\nProperties.hs:78:25:\r\n Could not deduce (Data.Vector.Unboxed.IVector [] a)\r\n from the context (Eq a,\r\n Ord a,\r\n Eq (v a),\r\n Ord (v a),\r\n Show a,\r\n Arbitrary a,\r\n Model a a,\r\n Show (v a),\r\n Arbitrary (v a),\r\n Model (v a) [a],\r\n Data.Vector.Unboxed.IVector v a,\r\n Show (v Bool),\r\n Arbitrary (v Bool),\r\n Model (v Bool) [Bool],\r\n Data.Vector.Unboxed.IVector v Bool)\r\n arising from a use of `Data.Vector.Unboxed.length'\r\n at Properties.hs:78:25-32\r\n Possible fix:\r\n add (Data.Vector.Unboxed.IVector [] a) to the context of\r\n the type signature for `testVersusLists'\r\n or add an instance declaration for\r\n (Data.Vector.Unboxed.IVector [] a)\r\n In the first argument of `eq1', namely\r\n `(Data.Vector.Unboxed.length :: v a -> Int)'\r\n In the expression:\r\n (Data.Vector.Unboxed.length :: v a -> Int) `eq1` length\r\n In the definition of `prop_length':\r\n prop_length = (Data.Vector.Unboxed.length :: v a -> Int)\r\n `eq1`\r\n length\r\n\r\nProperties.hs:83:25:\r\n No instance for (Data.Vector.Unboxed.IVector [] Bool)\r\n arising from a use of `Data.Vector.Unboxed.and'\r\n at Properties.hs:83:25-29\r\n Possible fix:\r\n add an instance declaration for\r\n (Data.Vector.Unboxed.IVector [] Bool)\r\n In the first argument of `eq1', namely\r\n `(Data.Vector.Unboxed.and :: v Bool -> Bool)'\r\n In the expression:\r\n (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and\r\n In the definition of `prop_and':\r\n prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and\r\n\r\nProperties.hs:95:24:\r\n Could not deduce (Eq ([a] -> [a]))\r\n from the context (Eq a,\r\n Ord a,\r\n Eq (v a),\r\n Ord (v a),\r\n Show a,\r\n Arbitrary a,\r\n Model a a,\r\n Show (v a),\r\n Arbitrary (v a),\r\n Model (v a) [a],\r\n Data.Vector.Unboxed.IVector v a,\r\n Show (v Bool),\r\n Arbitrary (v Bool),\r\n Model (v Bool) [Bool],\r\n Data.Vector.Unboxed.IVector v Bool)\r\n arising from a use of `eq2' at Properties.hs:95:24-86\r\n Possible fix:\r\n add (Eq ([a] -> [a])) to the context of\r\n the type signature for `testVersusLists'\r\n or add an instance declaration for (Eq ([a] -> [a]))\r\n In the expression:\r\n (Data.Vector.Unboxed.zipWith :: (a -> a -> a) -> v a -> v a -> v a)\r\n `eq2`\r\n zipWith\r\n In the definition of `prop_zipWith':\r\n prop_zipWith = (Data.Vector.Unboxed.zipWith ::\r\n (a -> a -> a) -> v a -> v a -> v a)\r\n `eq2`\r\n zipWith\r\n In the definition of `testVersusLists':\r\n testVersusLists _ = [testGroup \"Prelude\" prelude_tests,\r\n testGroup \"Data.List\" data_list_tests,\r\n testGroup \"Extras\" extra_tests]\r\n where\r\n prelude_tests = [testProperty \"length\" prop_length, ....]\r\n prop_length = (Data.Vector.Unboxed.length :: v a -> Int)\r\n `eq1`\r\n length\r\n prop_null = (Data.Vector.Unboxed.null :: v a -> Bool) `eq1` null\r\n prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and\r\n ....\r\n\r\nProperties.hs:114:25:\r\n Couldn't match expected type `v' against inferred type `[]'\r\n `v' is a rigid type variable bound by\r\n the type signature for `testVersusLists' at Properties.hs:19:28\r\n In the first argument of `eq2', namely\r\n `(enumFromTo :: a -> a -> v a)'\r\n In the expression: (enumFromTo :: a -> a -> v a) `eq2` enumFromTo\r\n In the definition of `prop_enumFromTo':\r\n prop_enumFromTo = (enumFromTo :: a -> a -> v a) `eq2` enumFromTo\r\n\r\nProperties.hs:115:76:\r\n Could not deduce (Enum a)\r\n from the context (Eq a,\r\n Ord a,\r\n Eq (v a),\r\n Ord (v a),\r\n Show a,\r\n Arbitrary a,\r\n Model a a,\r\n Show (v a),\r\n Arbitrary (v a),\r\n Model (v a) [a],\r\n Data.Vector.Unboxed.IVector v a,\r\n Show (v Bool),\r\n Arbitrary (v Bool),\r\n Model (v Bool) [Bool],\r\n Data.Vector.Unboxed.IVector v Bool)\r\n arising from a use of `enumFromThenTo' at Properties.hs:115:76-89\r\n Possible fix:\r\n add (Enum a) to the context of\r\n the type signature for `testVersusLists'\r\n In the second argument of `eq3', namely `enumFromThenTo'\r\n In the expression:\r\n (enumFromThenTo :: a -> a -> a -> v a) `eq3` enumFromThenTo\r\n In the definition of `prop_enumFromThenTo':\r\n prop_enumFromThenTo = (enumFromThenTo :: a -> a -> a -> v a)\r\n `eq3`\r\n enumFromThenTo\r\n\r\nProperties.hs:176:16:\r\n Could not deduce (Model [a] [a])\r\n from the context (Eq a,\r\n Ord a,\r\n Eq (v a),\r\n Ord (v a),\r\n Show a,\r\n Arbitrary a,\r\n Model a a,\r\n Show (v a),\r\n Arbitrary (v a),\r\n Model (v a) [a],\r\n Data.Vector.Unboxed.IVector v a,\r\n Show (v Bool),\r\n Arbitrary (v Bool),\r\n Model (v Bool) [Bool],\r\n Data.Vector.Unboxed.IVector v Bool)\r\n arising from a use of `eq2' at Properties.hs:176:16-71\r\n Possible fix:\r\n add (Model [a] [a]) to the context of\r\n the type signature for `testVersusLists'\r\n or add an instance declaration for (Model [a] [a])\r\n In the expression:\r\n (Data.Vector.Unboxed.snoc :: v a -> a -> v a) `eq2` snoc\r\n In the definition of `prop_snoc':\r\n prop_snoc = (Data.Vector.Unboxed.snoc :: v a -> a -> v a)\r\n `eq2`\r\n snoc\r\n In the definition of `testVersusLists':\r\n testVersusLists _ = [testGroup \"Prelude\" prelude_tests,\r\n testGroup \"Data.List\" data_list_tests,\r\n testGroup \"Extras\" extra_tests]\r\n where\r\n prelude_tests = [testProperty \"length\" prop_length, ....]\r\n prop_length = (Data.Vector.Unboxed.length :: v a -> Int)\r\n `eq1`\r\n length\r\n prop_null = (Data.Vector.Unboxed.null :: v a -> Bool) `eq1` null\r\n prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and\r\n ....\r\n}}}\r\n\r\nBut we probably still shouldn't get the ASSERT.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3012A little deriving for GADTs2019-07-07T19:05:53ZguestA little deriving for GADTsFor GADTs that are really enumerations, I think deriving Show should work.
E.g.
```
data T a where
Foo :: T Int
Bar :: T Bool
deriving (Show)
```
There's no(?) intricate behaviour of the derived functions, so why not?
> --...For GADTs that are really enumerations, I think deriving Show should work.
E.g.
```
data T a where
Foo :: T Int
Bar :: T Bool
deriving (Show)
```
There's no(?) intricate behaviour of the derived functions, so why not?
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"A little deriving for GADTs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"FeatureRequest","description":"For GADTs that are really enumerations, I think deriving Show should work.\r\nE.g.\r\n\r\n{{{\r\ndata T a where\r\n Foo :: T Int\r\n Bar :: T Bool\r\n deriving (Show)\r\n}}}\r\n\r\nThere's no(?) intricate behaviour of the derived functions, so why not?\r\n\r\n -- Lennart\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3013New simple GADT feature2019-07-07T19:05:53ZguestNew simple GADT featureIt's somewhat of an anomaly that the following does not work:
```
data T where
Foo, Bar :: Int -> T
```
Since the comma syntax works for type signatures and records it would be natural for it to work with GADTs.
<details><summary>...It's somewhat of an anomaly that the following does not work:
```
data T where
Foo, Bar :: Int -> T
```
Since the comma syntax works for type signatures and records it would be natural for it to work with GADTs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"New simple GADT feature","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"FeatureRequest","description":"It's somewhat of an anomaly that the following does not work:\r\n\r\n{{{\r\ndata T where\r\n Foo, Bar :: Int -> T\r\n}}}\r\n\r\nSince the comma syntax works for type signatures and records it would be natural for it to work with GADTs.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3014Any type being derived in Haskell 98 module2019-07-07T19:05:53Ziampure@gmail.comAny type being derived in Haskell 98 moduleLoad the attached module with ghci -ignore-dot-ghci, do :browse and observe the type of z, z :: GHC.Prim.Any -\> Double
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ----------------...Load the attached module with ghci -ignore-dot-ghci, do :browse and observe the type of z, z :: GHC.Prim.Any -\> Double
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Any type being derived in Haskell 98 module","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["any","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Load the attached module with ghci -ignore-dot-ghci, do :browse and observe the type of z, z :: GHC.Prim.Any -> Double\r\n\r\n\r\n\r\n ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3015Building packages using ghc (6.8.2) results in inconsistent error assembler m...2019-07-07T19:05:52ZakrohitBuilding packages using ghc (6.8.2) results in inconsistent error assembler messages```
akrohit@illusion:~/tmp/ghc-6.8.2$ uname -a
Linux illusion 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux
akrohit@illusion:~/tmp/ghc-6.8.2$ gcc --version
gcc (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23u...```
akrohit@illusion:~/tmp/ghc-6.8.2$ uname -a
Linux illusion 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux
akrohit@illusion:~/tmp/ghc-6.8.2$ gcc --version
gcc (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)
akrohit@illusion:~/tmp/ghc-6.8.2$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
```
Whenever installing any package using cabal or building packages locally results in some error messages of something like :
```
/tmp/ghc10273_0/ghc10273_0.s: Assembler messages:
/tmp/ghc10273_0/ghc10273_0.s:2502:0:
Error: junk at end of line, first unrecognized character is `8'
/tmp/ghc10273_0/ghc10273_0.s:2830:0:
Error: unknown pseudo-op: `.aligo'
<<ghc: 188196056 bytes, 25 GCs, 2710528/5779456 avg/max bytes residency (4 samples), 20M in use, 0.00 INIT (0.00 elapsed), 0.17 MUT (0.19 elapsed), 0.08 GC (0.10 elapsed) :ghc>>
make[2]: *** [Distribution/Compiler.o] Error 1
make[1]: *** [boot] Error 2
make: *** [stage1] Error 1
```
These error messages are not consistent.
Above also results with gcc version 4.3.16.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3016Long compile times, large memory use with static data in 6.102019-07-07T19:05:52ZdonsLong compile times, large memory use with static data in 6.10A collection of modules like this, when compiled together, are taking 2 1/2 hrs to compile with ghc 6.10, up from 30 mins with 6.8.x
This is slowing down a work project somewhat.
Attached is a sample module, that should illustrate the ...A collection of modules like this, when compiled together, are taking 2 1/2 hrs to compile with ghc 6.10, up from 30 mins with 6.8.x
This is slowing down a work project somewhat.
Attached is a sample module, that should illustrate the problem, when compiled ghc uses 2G and takes a few minutes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Long compile times, large memory use with static data in 6.10","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["data","static"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A collection of modules like this, when compiled together, are taking 2 1/2 hrs to compile with ghc 6.10, up from 30 mins with 6.8.x\r\n\r\nThis is slowing down a work project somewhat.\r\n\r\nAttached is a sample module, that should illustrate the problem, when compiled ghc uses 2G and takes a few minutes.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3017Type inference is broken when dealing with tuple type synonyms2019-07-07T19:05:51Zstraka.milanType inference is broken when dealing with tuple type synonymsI have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have
```
{-# LANGUAGE TypeFamilies #-}
class Coll c where
type Elem c
empty :: c
insert :: Elem c -> c -> c
data ListColl a = L [a]
instance Coll (List...I have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have
```
{-# LANGUAGE TypeFamilies #-}
class Coll c where
type Elem c
empty :: c
insert :: Elem c -> c -> c
data ListColl a = L [a]
instance Coll (ListColl a) where
type Elem (ListColl a) = a
empty = L []
insert x (L xs) = L (x:xs)
emptyL :: ListColl a
emptyL = empty
```
GHCI says
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
*Main> :t test1
test1 :: (Num (Elem c), Coll c) => c -> c
*Main> :t test2
test2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c
```
Shouldn't be the type of test2 be something like
`test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c`
?
When trying
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
test3 :: ListColl (Float, Float)
test3 = test2 emptyL
```
we get
```
*Main> :t test2
test2 : ((Float, Float) ~ Elem c, Coll c) => c -> c
```
and
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
test3 :: ListColl (Float, Float)
test3 = test2 emptyL
test3':: ListColl (Int, Int)
test3'= test2 emptyL
Couldn't match expected type `Int' against inferred type `Float'
Expected type: Elem (ListColl (Int, Int))
Inferred type: (Float, Float)
When generalising the type(s) for `test3''
Failed, modules loaded: none.
```
and
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
test4::(Num a, Num b) => ListColl (a, b)
test4 = test2 empty
Inferred type is less polymorphic than expected
Quantified type variable `b' escapes
Quantified type variable `a' escapes
When trying to generalise the type inferred for `test4'
Signature type: forall a b. (Num a, Num b) => ListColl (a, b)
Type to generalise: ListColl (a, b)
In the type signature for `test4'
When generalising the type(s) for `test4'
Failed, modules loaded: none.
```
When adding explicit type signature
`test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c`
all above examples works correctly, even if GHCI still says
```
:t test2
*Main> :t test2
test2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c
```
Last weird thing is
```
test5 _ = insert 0 emptyL
*Main> :t test5
test5 :: (Num a) => t -> ListColl a
test6 _ = insert (0,0) emptyL
Ambiguous type variable `t' in the constraint:
`Num t'
arising from the literal `0'
at /work/skola/haskell/grafy/Bug.hs:32:18
Probable fix: add a type signature that fixes these type variable(s)
Ambiguous type variable `t1' in the constraint:
`Num t1'
arising from the literal `0'
at /work/skola/haskell/grafy/Bug.hs:32:21
Probable fix: add a type signature that fixes these type variable(s)
Failed, modules loaded: none.
```
but adding
```
test6 :: (Num a, Num b, (a, b) ~ (Elem (ListColl c)), Coll (ListColl c)) => foo -> (ListColl c)
test6 _ = insert (0,0) emptyL
```
once again solves the problem.
Is this really a bug or just a feature :) I understand that in t1 \~ t2, the t1 and t2 can be arbitraty monotypes, so (a, b) should work, even with Num a and Num b, right?
Cheers,
Milan Straka
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type inference is broken when dealing with tuple type synonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nclass Coll c where\r\n type Elem c\r\n empty :: c\r\n insert :: Elem c -> c -> c\r\n\r\ndata ListColl a = L [a]\r\ninstance Coll (ListColl a) where\r\n type Elem (ListColl a) = a\r\n empty = L []\r\n insert x (L xs) = L (x:xs)\r\nemptyL :: ListColl a\r\nemptyL = empty\r\n}}}\r\n\r\nGHCI says\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\n\r\n*Main> :t test1\r\ntest1 :: (Num (Elem c), Coll c) => c -> c\r\n*Main> :t test2\r\ntest2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c\r\n}}}\r\n\r\nShouldn't be the type of test2 be something like\r\n{{{test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c}}}\r\n?\r\n\r\nWhen trying\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\ntest3 :: ListColl (Float, Float)\r\ntest3 = test2 emptyL\r\n}}}\r\nwe get\r\n{{{\r\n*Main> :t test2\r\ntest2 : ((Float, Float) ~ Elem c, Coll c) => c -> c\r\n}}}\r\n\r\nand\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\ntest3 :: ListColl (Float, Float)\r\ntest3 = test2 emptyL\r\ntest3':: ListColl (Int, Int)\r\ntest3'= test2 emptyL\r\n\r\n Couldn't match expected type `Int' against inferred type `Float'\r\n Expected type: Elem (ListColl (Int, Int))\r\n Inferred type: (Float, Float)\r\n When generalising the type(s) for `test3''\r\nFailed, modules loaded: none.\r\n}}}\r\nand\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\ntest4::(Num a, Num b) => ListColl (a, b)\r\ntest4 = test2 empty\r\n\r\n Inferred type is less polymorphic than expected\r\n Quantified type variable `b' escapes\r\n Quantified type variable `a' escapes\r\n When trying to generalise the type inferred for `test4'\r\n Signature type: forall a b. (Num a, Num b) => ListColl (a, b)\r\n Type to generalise: ListColl (a, b)\r\n In the type signature for `test4'\r\n When generalising the type(s) for `test4'\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nWhen adding explicit type signature\r\n{{{test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c}}}\r\nall above examples works correctly, even if GHCI still says\r\n{{{\r\n:t test2\r\n*Main> :t test2\r\ntest2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c\r\n}}}\r\n\r\nLast weird thing is\r\n{{{\r\ntest5 _ = insert 0 emptyL\r\n*Main> :t test5\r\ntest5 :: (Num a) => t -> ListColl a\r\n\r\ntest6 _ = insert (0,0) emptyL\r\n Ambiguous type variable `t' in the constraint:\r\n `Num t'\r\n arising from the literal `0'\r\n at /work/skola/haskell/grafy/Bug.hs:32:18\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n\r\n Ambiguous type variable `t1' in the constraint:\r\n `Num t1'\r\n arising from the literal `0'\r\n at /work/skola/haskell/grafy/Bug.hs:32:21\r\n Probable fix: add a type signature that fixes these type variable(s)\r\nFailed, modules loaded: none.\r\n}}}\r\nbut adding\r\n{{{\r\ntest6 :: (Num a, Num b, (a, b) ~ (Elem (ListColl c)), Coll (ListColl c)) => foo -> (ListColl c)\r\ntest6 _ = insert (0,0) emptyL\r\n}}}\r\nonce again solves the problem.\r\n\r\nIs this really a bug or just a feature :) I understand that in t1 ~ t2, the t1 and t2 can be arbitraty monotypes, so (a, b) should work, even with Num a and Num b, right?\r\n\r\nCheers,\r\nMilan Straka","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3018Constraints of function in record appears to nullifiy instance constraints.2019-07-07T19:05:51Zben.kavanaghConstraints of function in record appears to nullifiy instance constraints.If an field of a record that has constraints in its type, defining a value for this field appears to cause the compiler to ignore outer level constraints declared for an instance.
This problem restricts generic functions written in syb-...If an field of a record that has constraints in its type, defining a value for this field appears to cause the compiler to ignore outer level constraints declared for an instance.
This problem restricts generic functions written in syb-with-class and replib style to functions that do not have constraints.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Constraints of function in record appears to nullifiy instance constraints.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If an field of a record that has constraints in its type, defining a value for this field appears to cause the compiler to ignore outer level constraints declared for an instance.\r\n\r\nThis problem restricts generic functions written in syb-with-class and replib style to functions that do not have constraints. \r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3019sparc membar asm instruction requires mode parameter2019-07-07T19:05:51Zduncansparc membar asm instruction requires mode parameterThe new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_A...The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_ARCH
__asm__ __volatile__ ("lock; addq $0,0(%%rsp)" : : : "memory");
#elif powerpc_HOST_ARCH
__asm__ __volatile__ ("msync" : : : "memory");
#elif sparc_HOST_ARCH
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
#elif !defined(WITHSMP)
return;
#else
#error memory barriers unimplemented on this architecture
#endif
```
In particular for sparc the bit:
```
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
```
This is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.
Without this the assembler complains:
```
/usr/ccs/bin/as: "parallel/WSDeque.s", line 11: error: statement syntax
```
With `#StoreLoad` added it's fine.
Note also that the comment appears to be wrong
```
/* Sparc in TSO mode does not require write/write barriers. */
```
This is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"sparc membar asm instruction requires mode parameter","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.\r\n\r\n{{{\r\nEXTERN_INLINE void\r\nstore_load_barrier(void) {\r\n#if i386_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addl $0,0(%%esp)\" : : : \"memory\");\r\n#elif x86_64_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addq $0,0(%%rsp)\" : : : \"memory\");\r\n#elif powerpc_HOST_ARCH\r\n __asm__ __volatile__ (\"msync\" : : : \"memory\");\r\n#elif sparc_HOST_ARCH\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n#elif !defined(WITHSMP)\r\n return;\r\n#else\r\n#error memory barriers unimplemented on this architecture\r\n#endif\r\n}}}\r\n\r\nIn particular for sparc the bit:\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n}}}\r\n\r\nThis is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.\r\n\r\nWithout this the assembler complains:\r\n{{{\r\n/usr/ccs/bin/as: \"parallel/WSDeque.s\", line 11: error: statement syntax\r\n}}}\r\n\r\nWith `#StoreLoad` added it's fine.\r\n\r\nNote also that the comment appears to be wrong\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n}}}\r\nThis is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3020process 1.0.1.1 does not compile2019-07-07T19:05:51ZPhilonousprocess 1.0.1.1 does not compileCompiling haskell source using the process library version 1.0.1.1 via cabal-install gives compile errors.
process.hs :
```
import System.Process
main = runCommand "ls"
```
ghc process.hs :
```
process.o(.text+0xea): In function `Mai...Compiling haskell source using the process library version 1.0.1.1 via cabal-install gives compile errors.
process.hs :
```
import System.Process
main = runCommand "ls"
```
ghc process.hs :
```
process.o(.text+0xea): In function `Main_main_info':
: undefined reference to `processzm1zi0zi1zi1_SystemziProcess_runCommand_closure'
process.o(.text+0x1c3): In function `__stginit_Main_':
: undefined reference to `__stginit_processzm1zi0zi1zi1_SystemziProcess_'
process.o(.data+0x28): In function `Main_main_srt':
: undefined reference to `processzm1zi0zi1zi1_SystemziProcess_runCommand_closure'
```
just importing the library and not using anything it exports still
yields the first of the three errors.
ghci crashes upon compilation of process-1.0.1.1:
```
GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :module +System.Process
Prelude System.Process> runCommand "ls"
Loading package old-locale-1.0.0.0 ... linking ... done.
Loading package old-time-1.0.0.0 ... linking ... done.
Loading package filepath-1.1.0.0 ... linking ... done.
Loading package directory-1.0.0.1 ... linking ... done.
Loading package unix-2.3.0.1 ... linking ... done.
Loading package process-1.0.1.1 ... linking ... <interactive>: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c18012a8
(GHC version 6.8.3 for x86_64_unknown_freebsd)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort (core dumped)
```
ghc --version :
```
The Glorious Glasgow Haskell Compilation System, version 6.8.3
```
uname -v
```
FreeBSD 7.1-RELEASE-p1 #0: Tue Jan 13 00:58:07 UTC 2009 root@:/usr/obj/usr/src/sys/GENERIC
```
ghc-pkg -list
```
/usr/local/lib/ghc-6.8.3/package.conf:
Cabal-1.2.4.0, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.1.0.0,
base-3.0.2.0, bytestring-0.9.0.1.1, cgi-3001.1.6.0,
containers-0.1.0.2, directory-1.0.0.1, fgl-5.4.2.0,
filepath-1.1.0.0, (ghc-6.8.3), haskell-src-1.0.1.2,
haskell98-1.0.1.0, hpc-0.5.0.1, html-1.0.1.1, mtl-1.1.0.1,
network-2.2.0.0, old-locale-1.0.0.0, old-time-1.0.0.0,
packedstring-0.1.0.0, parallel-1.0.0.1, parsec-2.1.0.1,
pretty-1.0.0.0, process-1.0.0.1, random-1.0.0.0, readline-1.0.1.0,
regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2,
rts-1.0, stm-2.1.1.1, template-haskell-2.2.0.0, time-1.1.2.1,
unix-2.3.0.1, xhtml-3000.2.0.0
/home/******/.ghc/x86_64-freebsd-6.8.3/package.conf:
Cabal-1.6.0.1, HTTP-3001.1.3, X11-1.4.5, X11-xft-0.3,
process-1.0.1.1, utf8-string-0.3.4, xmonad-0.8.1,
xmonad-contrib-0.8.1, zlib-0.4.0.4
```
process 1.0.0.0 works just fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"process 1.0.1.1 compile","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling haskell source using the process library version 1.0.1.1 via cabal-install gives compile errors.\r\n\r\nprocess.hs :\r\n{{{\r\nimport System.Process\r\nmain = runCommand \"ls\"\r\n}}}\r\n\r\nghc process.hs :\r\n\r\n{{{\r\nprocess.o(.text+0xea): In function `Main_main_info':\r\n: undefined reference to `processzm1zi0zi1zi1_SystemziProcess_runCommand_closure'\r\nprocess.o(.text+0x1c3): In function `__stginit_Main_':\r\n: undefined reference to `__stginit_processzm1zi0zi1zi1_SystemziProcess_'\r\nprocess.o(.data+0x28): In function `Main_main_srt':\r\n: undefined reference to `processzm1zi0zi1zi1_SystemziProcess_runCommand_closure'\r\n}}}\r\n\r\njust importing the library and not using anything it exports still\r\nyields the first of the three errors.\r\n\r\nghci crashes upon compilation of process-1.0.1.1:\r\n\r\n{{{\r\nGHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :module +System.Process \r\nPrelude System.Process> runCommand \"ls\"\r\nLoading package old-locale-1.0.0.0 ... linking ... done.\r\nLoading package old-time-1.0.0.0 ... linking ... done.\r\nLoading package filepath-1.1.0.0 ... linking ... done.\r\nLoading package directory-1.0.0.1 ... linking ... done.\r\nLoading package unix-2.3.0.1 ... linking ... done.\r\nLoading package process-1.0.1.1 ... linking ... <interactive>: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c18012a8\r\n (GHC version 6.8.3 for x86_64_unknown_freebsd)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort (core dumped)\r\n}}}\r\n\r\nghc --version :\r\n{{{\r\nThe Glorious Glasgow Haskell Compilation System, version 6.8.3\r\n}}}\r\nuname -v\r\n{{{\r\nFreeBSD 7.1-RELEASE-p1 #0: Tue Jan 13 00:58:07 UTC 2009 root@:/usr/obj/usr/src/sys/GENERIC \r\n}}}\r\n\r\nghc-pkg -list \r\n{{{\r\n/usr/local/lib/ghc-6.8.3/package.conf:\r\n Cabal-1.2.4.0, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.1.0.0,\r\n base-3.0.2.0, bytestring-0.9.0.1.1, cgi-3001.1.6.0,\r\n containers-0.1.0.2, directory-1.0.0.1, fgl-5.4.2.0,\r\n filepath-1.1.0.0, (ghc-6.8.3), haskell-src-1.0.1.2,\r\n haskell98-1.0.1.0, hpc-0.5.0.1, html-1.0.1.1, mtl-1.1.0.1,\r\n network-2.2.0.0, old-locale-1.0.0.0, old-time-1.0.0.0,\r\n packedstring-0.1.0.0, parallel-1.0.0.1, parsec-2.1.0.1,\r\n pretty-1.0.0.0, process-1.0.0.1, random-1.0.0.0, readline-1.0.1.0,\r\n regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2,\r\n rts-1.0, stm-2.1.1.1, template-haskell-2.2.0.0, time-1.1.2.1,\r\n unix-2.3.0.1, xhtml-3000.2.0.0\r\n/home/******/.ghc/x86_64-freebsd-6.8.3/package.conf:\r\n Cabal-1.6.0.1, HTTP-3001.1.3, X11-1.4.5, X11-xft-0.3,\r\n process-1.0.1.1, utf8-string-0.3.4, xmonad-0.8.1,\r\n xmonad-contrib-0.8.1, zlib-0.4.0.4\r\n}}}\r\nprocess 1.0.0.0 works just fine. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3021A way to programmatically insert marks into heap profiling output2019-07-07T19:05:51ZSamuel BronsonA way to programmatically insert marks into heap profiling outputThis would be useful for e.g. marking compiler phases.
Hmm, this would be more useful if the "MARK" record type had a string field...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...This would be useful for e.g. marking compiler phases.
Hmm, this would be more useful if the "MARK" record type had a string field...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | SamB |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"A way to programmatically insert marks into heap profiling output","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["profiling"],"differentials":[],"test_case":"","architecture":"","cc":["SamB"],"type":"FeatureRequest","description":"This would be useful for e.g. marking compiler phases.\r\n\r\nHmm, this would be more useful if the \"MARK\" record type had a string field...","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3022ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO2019-07-07T19:05:50Zguestghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCOghci told me to report a bug:
```
$ ghci 18.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ...ghci told me to report a bug:
```
$ ghci 18.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( 18.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
linkBCO: >= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ uname -a
Linux ogum 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686 GNU/Linux
```
I've attached the offending file, here's the md5sum:
```
$ md5sum 18.hs
1594c7d5522d0b1d7f1a70f6f3dfc24a 18.hs
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghci told me to report a bug:\r\n{{{\r\n$ ghci 18.hs\r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( 18.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n linkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\n\r\n$ ghci --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.1\r\n$ uname -a\r\nLinux ogum 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686 GNU/Linux\r\n}}}\r\n\r\nI've attached the offending file, here's the md5sum:\r\n{{{\r\n$ md5sum 18.hs \r\n1594c7d5522d0b1d7f1a70f6f3dfc24a 18.hs\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3023Wrong inferred type shown2019-07-07T19:05:50ZguestWrong inferred type shownWhen the warning for missing type signatures is turned on the displayed type is sometimes totally bogus.
```
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-}
module Bug where
class C a b | a -> b, b ...When the warning for missing type signatures is turned on the displayed type is sometimes totally bogus.
```
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-}
module Bug where
class C a b | a -> b, b -> a where
f :: a -> b
instance C Int Bool where
f = undefined
instance (C a c, C b d) => C (a -> b) (c -> d) where
f = undefined
foo :: Int -> Int
foo = undefined
bar = f foo
```
GHC says:
```
Warning: Definition but no type signature for `bar'
Inferred type: bar :: c -> d
```
The type for bar is, of course, Bool-\>Bool, and nothing else.
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Wrong inferred type shown","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"When the warning for missing type signatures is turned on the displayed type is sometimes totally bogus.\r\n\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-}\r\nmodule Bug where\r\n\r\nclass C a b | a -> b, b -> a where\r\n f :: a -> b\r\n\r\ninstance C Int Bool where\r\n f = undefined\r\ninstance (C a c, C b d) => C (a -> b) (c -> d) where\r\n f = undefined\r\n\r\nfoo :: Int -> Int\r\nfoo = undefined\r\n\r\nbar = f foo\r\n}}}\r\nGHC says:\r\n{{{\r\n Warning: Definition but no type signature for `bar'\r\n Inferred type: bar :: c -> d\r\n}}}\r\nThe type for bar is, of course, Bool->Bool, and nothing else.\r\n\r\n -- Lennart\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3024Rewrite hp2ps in Haskell2019-07-07T19:05:50ZSamuel BronsonRewrite hp2ps in HaskellRight now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make it, among other things, more tolerant to incomplete records.Right now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make it, among other things, more tolerant to incomplete records.https://gitlab.haskell.org/ghc/ghc/-/issues/3025Possible PiDigits memory explosion regression2019-07-07T19:05:49ZjapplePossible PiDigits memory explosion regressionThis bug is reported from http://axman6.homeip.net/blog/2009/02/shootout-pidigits-program-kinda-sucks-and-possibly-so-does-ghc.html . I will duplicate some content here, since blogs hosted at \*.homeip.net seem likely to be down more tha...This bug is reported from http://axman6.homeip.net/blog/2009/02/shootout-pidigits-program-kinda-sucks-and-possibly-so-does-ghc.html . I will duplicate some content here, since blogs hosted at \*.homeip.net seem likely to be down more than the average blog.
[PiDigits on 6.10](http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=ghc&id=1) takes over 300mb of memory, but [wren ng thornton](http://winterkoninkje.livejournal.com/) notes that the program only takes 3mb when compiled with 6.8.2.
BTW, I'm on linux x86, while the shootout is on x86_64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Possible PiDigits memory explosion regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This bug is reported from http://axman6.homeip.net/blog/2009/02/shootout-pidigits-program-kinda-sucks-and-possibly-so-does-ghc.html . I will duplicate some content here, since blogs hosted at *.homeip.net seem likely to be down more than the average blog.\r\n\r\n[http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=ghc&id=1 PiDigits on 6.10] takes over 300mb of memory, but [http://winterkoninkje.livejournal.com/ wren ng thornton] notes that the program only takes 3mb when compiled with 6.8.2.\r\n\r\nBTW, I'm on linux x86, while the shootout is on x86_64.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3026GHCi segfault2019-07-07T19:05:49ZPorgesGHCi segfaultThis may be libedit's fault, but I can't tell :)
How to replicate:
Load up GHCi, hold the up-arrow. Segfault!
Here's a backtrace:
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7e546b0 (LWP 99...This may be libedit's fault, but I can't tell :)
How to replicate:
Load up GHCi, hold the up-arrow. Segfault!
Here's a backtrace:
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7e546b0 (LWP 9959)]
0xb808133c in ?? () from /usr/lib/libedit.so.2
(gdb) bt
#0 0xb808133c in ?? () from /usr/lib/libedit.so.2
#1 0xb8085e1a in ?? () from /usr/lib/libedit.so.2
#2 0xb8088164 in el_gets () from /usr/lib/libedit.so.2
#3 0xb8095d24 in readline () from /usr/lib/libedit.so.2
#4 0x08aaea00 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3027Specialisation rules fail because dictionary projections do not match2019-07-07T19:05:49Zmalcolm wallaceSpecialisation rules fail because dictionary projections do not matchHere is an apparent bug in ghc's specialisation rules. The rewrite rule
generated by a SPECIALISE pragma seems to want to pattern-match on exact
dictionaries (as well as types). But the compiler is not necessarily
able to fully resolve d...Here is an apparent bug in ghc's specialisation rules. The rewrite rule
generated by a SPECIALISE pragma seems to want to pattern-match on exact
dictionaries (as well as types). But the compiler is not necessarily
able to fully resolve dictionaries before the rules are supposed to
fire.
First, the source code we want to specialise:
```
{-# SPECIALISE
hedgehog :: Float -> Vector3 Float
-> [Cell_8 (Coord3 Float)]
-> [Cell_8 (Vector3 Float)]
-> [(Coord3 Float, Coord3 Float)]
#-}
hedgehog :: ( Fractional a, Cell cell vert, Eq vert
, Geom coord, Geom vector, Embed vector coord ) =>
a -> vector a
-> [cell (coord a)]
-> [cell (vector a)]
-> [(coord a, coord a)]
```
The core + interface generated for this module contains the rule:
```
"SPEC Hedgehog.hedgehog" ALWAYS forall
Hedgehog.hedgehog @ GHC.Float.Float
@ RectGrid.Cell_8
@ RectGrid.MyVertex
@ Geometries.Coord3
@ Geometries.Vector3
GHC.Float.$f16
RectGrid.$f2
RectGrid.$f10
Geometries.$f5
Geometries.$f3
Geometries.$f1
```
But in a different module (Viewer.hs), here is what the usage site looks like just
before the specialisation rules are supposed to fire:
```
hedgehog_aWr =
Hedgehog.hedgehog
@ GHC.Float.Float
@ RectGrid.Cell_8
@ RectGrid.MyVertex
@ Geometries.Coord3
@ Geometries.Vector3
GHC.Float.$f16
RectGrid.$f2
RectGrid.$f10
(Dataset.$p2Embed @ Geometries.Vector3 @ Geometries.Coord3 Geometries.$f1)
(Dataset.$p1Embed @ Geometries.Vector3 @ Geometries.Coord3 Geometries.$f1)
Geometries.$f1
```
Notice how there are a couple of dictionary projection functions still sitting
there, so although some of the dictionaries match, not all do, and the
rule does not fire. However, later the worker-wrapper transformation
is able to resolve those outstanding dictionaries, giving eventually:
```
hedgehog_r2at =
Hedgehog.$whedgehog
@ GHC.Float.Float
@ RectGrid.Cell_8
@ RectGrid.MyVertex
@ Geometries.Coord3
@ Geometries.Vector3
GHC.Float.$f16
RectGrid.$f2
Geometries.$f5
Geometries.$f3
Geometries.$f1
```
So I'm left calling the worker for the polymorphic version of the
function, rather than the specialised monomorphic code I wanted. Given
how many dictionaries are involved, and that this is the inner loop of
the program, I'm hoping there is a big performance win waiting for me,
if only I can get that specialised code to run!
A code archive is attached, to help you reproduce the behaviour.
I have cut down the code considerably already, but it is still spread
over 5 modules: I was unable to cut it down much further without
the bug disappearing (probably through inlining or something).
Classes are defined in Dataset.hs, instances in Geometries.hs.
The code I want to specialise is in Hedgehog.hs, and the usage site
is in Viewer.hs (the main program).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| 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":"Specialisation rules fail because dictionary projections do not match","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is an apparent bug in ghc's specialisation rules. The rewrite rule\r\ngenerated by a SPECIALISE pragma seems to want to pattern-match on exact\r\ndictionaries (as well as types). But the compiler is not necessarily\r\nable to fully resolve dictionaries before the rules are supposed to\r\nfire.\r\n\r\nFirst, the source code we want to specialise:\r\n{{{\r\n {-# SPECIALISE\r\n hedgehog :: Float -> Vector3 Float\r\n -> [Cell_8 (Coord3 Float)]\r\n -> [Cell_8 (Vector3 Float)]\r\n -> [(Coord3 Float, Coord3 Float)]\r\n #-}\r\n hedgehog :: ( Fractional a, Cell cell vert, Eq vert\r\n , Geom coord, Geom vector, Embed vector coord ) =>\r\n a -> vector a\r\n -> [cell (coord a)]\r\n -> [cell (vector a)]\r\n -> [(coord a, coord a)]\r\n}}}\r\n\r\nThe core + interface generated for this module contains the rule:\r\n{{{\r\n \"SPEC Hedgehog.hedgehog\" ALWAYS forall\r\n Hedgehog.hedgehog @ GHC.Float.Float\r\n @ RectGrid.Cell_8\r\n @ RectGrid.MyVertex\r\n @ Geometries.Coord3\r\n @ Geometries.Vector3\r\n GHC.Float.$f16\r\n RectGrid.$f2\r\n RectGrid.$f10\r\n Geometries.$f5\r\n Geometries.$f3\r\n Geometries.$f1\r\n}}}\r\n\r\nBut in a different module (Viewer.hs), here is what the usage site looks like just\r\nbefore the specialisation rules are supposed to fire:\r\n{{{\r\nhedgehog_aWr =\r\n Hedgehog.hedgehog\r\n @ GHC.Float.Float\r\n @ RectGrid.Cell_8\r\n @ RectGrid.MyVertex\r\n @ Geometries.Coord3\r\n @ Geometries.Vector3\r\n GHC.Float.$f16\r\n RectGrid.$f2\r\n RectGrid.$f10\r\n (Dataset.$p2Embed @ Geometries.Vector3 @ Geometries.Coord3 Geometries.$f1)\r\n (Dataset.$p1Embed @ Geometries.Vector3 @ Geometries.Coord3 Geometries.$f1)\r\n Geometries.$f1\r\n}}}\r\n\r\nNotice how there are a couple of dictionary projection functions still sitting\r\nthere, so although some of the dictionaries match, not all do, and the\r\nrule does not fire. However, later the worker-wrapper transformation\r\nis able to resolve those outstanding dictionaries, giving eventually:\r\n{{{\r\nhedgehog_r2at =\r\n Hedgehog.$whedgehog\r\n @ GHC.Float.Float\r\n @ RectGrid.Cell_8\r\n @ RectGrid.MyVertex\r\n @ Geometries.Coord3\r\n @ Geometries.Vector3\r\n GHC.Float.$f16\r\n RectGrid.$f2\r\n Geometries.$f5\r\n Geometries.$f3\r\n Geometries.$f1\r\n}}}\r\n\r\nSo I'm left calling the worker for the polymorphic version of the\r\nfunction, rather than the specialised monomorphic code I wanted. Given\r\nhow many dictionaries are involved, and that this is the inner loop of\r\nthe program, I'm hoping there is a big performance win waiting for me,\r\nif only I can get that specialised code to run!\r\n\r\nA code archive is attached, to help you reproduce the behaviour.\r\nI have cut down the code considerably already, but it is still spread\r\nover 5 modules: I was unable to cut it down much further without\r\nthe bug disappearing (probably through inlining or something).\r\n\r\nClasses are defined in Dataset.hs, instances in Geometries.hs.\r\nThe code I want to specialise is in Hedgehog.hs, and the usage site\r\nis in Viewer.hs (the main program).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3028what_next error2019-07-07T19:05:49Zosuchwhat_next errorC:\\Documents and Settings\\ondrej\\Desktop\\Prob\>del \*.o
C:\\Documents and Settings\\ondrej\\Desktop\\Prob\>ghc --make -o par2 Par2.hs par1.hs
\[1 of 2\] Compiling Par1 ( par1.hs, par1.o )
\[2 of 2\] Compiling Main ( Par2.hs, Par2.o...C:\\Documents and Settings\\ondrej\\Desktop\\Prob\>del \*.o
C:\\Documents and Settings\\ondrej\\Desktop\\Prob\>ghc --make -o par2 Par2.hs par1.hs
\[1 of 2\] Compiling Par1 ( par1.hs, par1.o )
\[2 of 2\] Compiling Main ( Par2.hs, Par2.o )
Linking par2.exe ...
C:\\Documents and Settings\\ondrej\\Desktop\\Prob\>par2.exe -d 10 -t 2 -r 100000 -s 1
0
\[('d',"10"),('r',"100000"),('s',"10"),('t',"2")\]
about to start generator thread
about to start consumer threads
done
Result for thread 1 is Just 499799.8385894363
par2.exe: internal error: schedule: invalid what_next field
(GHC version 6.10.1 for i386_unknown_mingw32)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"what_next error","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"C:\\Documents and Settings\\ondrej\\Desktop\\Prob>del *.o\r\n\r\nC:\\Documents and Settings\\ondrej\\Desktop\\Prob>ghc --make -o par2 Par2.hs par1.hs\r\n\r\n[1 of 2] Compiling Par1 ( par1.hs, par1.o )\r\n[2 of 2] Compiling Main ( Par2.hs, Par2.o )\r\nLinking par2.exe ...\r\n\r\n\r\nC:\\Documents and Settings\\ondrej\\Desktop\\Prob>par2.exe -d 10 -t 2 -r 100000 -s 1\r\n0\r\n[('d',\"10\"),('r',\"100000\"),('s',\"10\"),('t',\"2\")]\r\nabout to start generator thread\r\nabout to start consumer threads\r\ndone\r\nResult for thread 1 is Just 499799.8385894363\r\npar2.exe: internal error: schedule: invalid what_next field\r\n (GHC version 6.10.1 for i386_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\r\nPlease contact the application's support team for more information.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3029ghc panic while installing hs-Crypto package (via macport)2019-07-07T19:05:49Zmreza101ghc panic while installing hs-Crypto package (via macport)Here is the bug dump after it failed to build the package.
Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-Crypto/work/...Here is the bug dump after it failed to build the package.
Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v" returned error 1
Command output: In the instance declaration for `Integral (LargeKey a b)'
Data/LargeWord.hs:137:9:
Warning: No explicit method nor default method for `toRational'
> In the instance declaration for \`Real (LargeKey a b)'
Data/LargeWord.hs:140:9:
> Warning: No explicit method nor default method for `toEnum'
> In the instance declaration for `Enum (LargeKey a b)'
Data/LargeWord.hs:140:9:
> Warning: No explicit method nor default method for `fromEnum'
> In the instance declaration for `Enum (LargeKey a b)'
\[10 of 11\] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o )
\[11 of 11\] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )
Linking dist/build/SymmetricTest/SymmetricTest ...
Building executable: SHA1Test...
Creating dist/build/SHA1Test (and its parents)
Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents)
/opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all-packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs
\[1 of 4\] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
\[2 of 4\] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )
\[3 of 4\] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )
\[4 of 4\] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
> (GHC version 6.10.1 for i386-apple-darwin):
RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Error: Status 1 encountered during processing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic while installing hs-Crypto package (via macport)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["Crypto"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is the bug dump after it failed to build the package. \r\n\r\nError: Target org.macports.build returned: shell command \"cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v\" returned error 1\r\nCommand output: In the instance declaration for `Integral (LargeKey a b)'\r\n\r\nData/LargeWord.hs:137:9:\r\n Warning: No explicit method nor default method for `toRational'\r\n In the instance declaration for `Real (LargeKey a b)'\r\n\r\nData/LargeWord.hs:140:9:\r\n Warning: No explicit method nor default method for `toEnum'\r\n In the instance declaration for `Enum (LargeKey a b)'\r\n\r\nData/LargeWord.hs:140:9:\r\n Warning: No explicit method nor default method for `fromEnum'\r\n In the instance declaration for `Enum (LargeKey a b)'\r\n[10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o )\r\n[11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )\r\nLinking dist/build/SymmetricTest/SymmetricTest ...\r\nBuilding executable: SHA1Test...\r\nCreating dist/build/SHA1Test (and its parents)\r\nCreating dist/build/SHA1Test/SHA1Test-tmp (and its parents)\r\n/opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all-packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs\r\n[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )\r\n[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )\r\n[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )\r\n[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tRegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\nError: Status 1 encountered during processing.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3030GHCI Loading Compiled Modules Under Windows XP Crashes2019-07-07T19:05:48ZjburckGHCI Loading Compiled Modules Under Windows XP Crasheswhenever I load any compiled code under GHCI I get the following when it tries to execute:
: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
> loadObj: failed
Please report this as a GHC bug: http:/...whenever I load any compiled code under GHCI I get the following when it tries to execute:
: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
> loadObj: failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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 Loading Compiled Modules Under Windows XP Crashes","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"whenever I load any compiled code under GHCI I get the following when it tries to execute:\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-mingw32):\r\n loadObj: failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3031-fwarn-unrecognised-pragmas is not documented2019-07-07T19:05:48ZSimon Marlow-fwarn-unrecognised-pragmas is not documentedSomehow this slipped through the net...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type ...Somehow this slipped through the net...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fwarn-unrecognised-pragmas is not documented","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Somehow this slipped through the net...","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3032would be nice if -fno-code and --make worked together2019-07-07T19:05:48Zduncanwould be nice if -fno-code and --make worked togetherWe had a Cabal feature request to omit linking to make it quicker in the use case that we just want to check that a package typechecks ok.
Omitting liking is good but we could save more time by omitting code generation too. The `-fno-co...We had a Cabal feature request to omit linking to make it quicker in the use case that we just want to check that a package typechecks ok.
Omitting liking is good but we could save more time by omitting code generation too. The `-fno-code` would seem to be what we want in this case but it looks like it only works with batch mode and not `--make` mode. What happens at the moment when one uses `-fno-code --make` is that ghc cannot find the dependent modules, though it is not clear that it is actually looking for `.hi` files in any particular location. This is with 6.8.2, I've not checked with 6.10 but I assume it is the same.
So if it looks like it would not be too hard to do, then letting `-fno-code` work with `--make` would be occasionally useful. The expected result would be to write out the `.hi` files for all the modules but not the corresponding `.o` files. When combined with `-O0` we might hope it to be a bit quicker than normal builds.
Of course it would not work in the case of template Haskell, but Cabal would just avoid using `-fno-code` if the package uses TH.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| 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":"would be nice if -fno-code and --make worked together","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"We had a Cabal feature request to omit linking to make it quicker in the use case that we just want to check that a package typechecks ok.\r\n\r\nOmitting liking is good but we could save more time by omitting code generation too. The `-fno-code` would seem to be what we want in this case but it looks like it only works with batch mode and not `--make` mode. What happens at the moment when one uses `-fno-code --make` is that ghc cannot find the dependent modules, though it is not clear that it is actually looking for `.hi` files in any particular location. This is with 6.8.2, I've not checked with 6.10 but I assume it is the same.\r\n\r\nSo if it looks like it would not be too hard to do, then letting `-fno-code` work with `--make` would be occasionally useful. The expected result would be to write out the `.hi` files for all the modules but not the corresponding `.o` files. When combined with `-O0` we might hope it to be a bit quicker than normal builds.\r\n\r\nOf course it would not work in the case of template Haskell, but Cabal would just avoid using `-fno-code` if the package uses TH.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/3033numerical error introduced by -O12019-07-07T19:05:47Zrolandnumerical error introduced by -O1```
f x = x * 1000000.1
g y True = y
g y False = g y True
z = let x = 100000000000.0 in
f x - g (f x) True
main = putStrLn (show z)
```
This program prints "-2.328125" when compiled with "-O1".
Running `main` from within ghci gi...```
f x = x * 1000000.1
g y True = y
g y False = g y True
z = let x = 100000000000.0 in
f x - g (f x) True
main = putStrLn (show z)
```
This program prints "-2.328125" when compiled with "-O1".
Running `main` from within ghci gives "0.0", as it should.
Occurs under Mac OS and Linux (both x86).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"numerical error introduced by -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nf x = x * 1000000.1\r\n\r\ng y True = y\r\ng y False = g y True\r\n\r\nz = let x = 100000000000.0 in\r\n f x - g (f x) True\r\n\r\nmain = putStrLn (show z)\r\n}}}\r\n\r\nThis program prints \"-2.328125\" when compiled with \"-O1\".\r\nRunning {{{main}}} from within ghci gives \"0.0\", as it should.\r\n\r\nOccurs under Mac OS and Linux (both x86).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3034divInt# floated into a position which leads to low arity2020-02-26T21:25:19ZbatterseapowerdivInt# floated into a position which leads to low arityTyson Whitehead saw this in the Core output of one of his programs compiled using the MTL StateT:
```
$wdigit_s1GR [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int#
-> GHC.Types.Int
...Tyson Whitehead saw this in the Core output of one of his programs compiled using the MTL StateT:
```
$wdigit_s1GR [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int#
-> GHC.Types.Int
-> Control.Monad.State.Strict.StateT
GHC.Types.Int
(Control.Monad.Error.ErrorT
GHC.Base.String
Control.Monad.Identity.Identity)
(GHC.Types.Int, GHC.Types.Int)
[Arity 1
Str: DmdType L]
$wdigit_s1GR =
\ (ww_X1H6 :: GHC.Prim.Int#) ->
let {
lvl_s1H5 [ALWAYS Just D(T)] :: GHC.Types.Int
[Str: DmdType]
lvl_s1H5 =
case GHC.Prim.-# 2147483647 ww_X1H6 of wild2_a1xs [ALWAYS Just L] {
__DEFAULT ->
case GHC.Base.divInt# wild2_a1xs 10
of wild21_a1xt [ALWAYS Just L] { __DEFAULT ->
GHC.Types.I# wild21_a1xt
};
(-2147483648) -> lvl_s1Ha
} } in
(\ (eta_X1nK :: GHC.Types.Int) (eta_s1Dl :: GHC.Types.Int) ->
case eta_s1Dl
of y_XrP [ALWAYS Just A] { GHC.Types.I# ipv_s19d [ALWAYS Just L] ->
case GHC.Prim.<=# ipv_s19d 214748363
of wild_a19h [ALWAYS Dead Just A] {
GHC.Bool.False ->
case lvl_s1H5
of wild1_X1zB [ALWAYS Just A]
{ GHC.Types.I# y_X1zG [ALWAYS Just L] ->
case GHC.Prim.<=# ipv_s19d y_X1zG
of wild_X1z [ALWAYS Dead Just A] {
GHC.Bool.False ->
a_s1Hk
`cast` (right
```
This REALLY SHOULD have arity 3 because that allows:
- More worker/wrapper
- Less sharing of trivial partial applications elsewhere in his program
Here is my reply to him, explaining why it all happens:
```
Yes - GHC wants to share the work of (maxBound-x)`div`10 between
several partial applications of "digit". This is usually a good idea,
but in this case it sucks because it's resulted in a massively
increased arity. IMHO GHC should fix this by:
* Marking divInt# INLINE in the base library. This would result in
your code would just containing uses of quotInt#
* Making some operations cheap even if they may fail
(PrimOp.primpOpIsCheap should change). Though this might mean that we
turn non-terminating programs into terminating ones (such operations
get pushed inside lambdas) but this is consistent with our treatment
of lambdas generally.
Actually, your divInt# call wouldn't even usually be floated out to
between two lambdas, but at the time FloatOut runs there is something
in between the \x lambda and the lambdas from the state monad - the
monadic bind operator! So FloatOut feels free to move the computation
for "x" up even though that >>= will go away as soon as we run the
simplifier. What a disaster!
```
So one of FloatOut and primOpIsCheap probably needs to be fixed.
I've attached a program that can reproduce this issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"divInt# floated into a position which leads to low arity","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tyson Whitehead saw this in the Core output of one of his programs compiled using the MTL StateT:\r\n\r\n{{{\r\n$wdigit_s1GR [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int#\r\n -> GHC.Types.Int\r\n -> Control.Monad.State.Strict.StateT\r\n GHC.Types.Int\r\n (Control.Monad.Error.ErrorT\r\n GHC.Base.String\r\n Control.Monad.Identity.Identity)\r\n (GHC.Types.Int, GHC.Types.Int)\r\n[Arity 1\r\nStr: DmdType L]\r\n$wdigit_s1GR =\r\n\\ (ww_X1H6 :: GHC.Prim.Int#) ->\r\n let {\r\n lvl_s1H5 [ALWAYS Just D(T)] :: GHC.Types.Int\r\n [Str: DmdType]\r\n lvl_s1H5 =\r\n case GHC.Prim.-# 2147483647 ww_X1H6 of wild2_a1xs [ALWAYS Just L] {\r\n __DEFAULT ->\r\n case GHC.Base.divInt# wild2_a1xs 10\r\n of wild21_a1xt [ALWAYS Just L] { __DEFAULT ->\r\n GHC.Types.I# wild21_a1xt\r\n };\r\n (-2147483648) -> lvl_s1Ha\r\n } } in\r\n (\\ (eta_X1nK :: GHC.Types.Int) (eta_s1Dl :: GHC.Types.Int) ->\r\n case eta_s1Dl\r\n of y_XrP [ALWAYS Just A] { GHC.Types.I# ipv_s19d [ALWAYS Just L] ->\r\n case GHC.Prim.<=# ipv_s19d 214748363\r\n of wild_a19h [ALWAYS Dead Just A] {\r\n GHC.Bool.False ->\r\n case lvl_s1H5\r\n of wild1_X1zB [ALWAYS Just A]\r\n { GHC.Types.I# y_X1zG [ALWAYS Just L] ->\r\n case GHC.Prim.<=# ipv_s19d y_X1zG\r\n of wild_X1z [ALWAYS Dead Just A] {\r\n GHC.Bool.False ->\r\n a_s1Hk\r\n `cast` (right\r\n}}}\r\n\r\nThis REALLY SHOULD have arity 3 because that allows:\r\n * More worker/wrapper\r\n * Less sharing of trivial partial applications elsewhere in his program\r\n\r\nHere is my reply to him, explaining why it all happens:\r\n\r\n{{{\r\nYes - GHC wants to share the work of (maxBound-x)`div`10 between\r\nseveral partial applications of \"digit\". This is usually a good idea,\r\nbut in this case it sucks because it's resulted in a massively\r\nincreased arity. IMHO GHC should fix this by:\r\n* Marking divInt# INLINE in the base library. This would result in\r\nyour code would just containing uses of quotInt#\r\n* Making some operations cheap even if they may fail\r\n(PrimOp.primpOpIsCheap should change). Though this might mean that we\r\nturn non-terminating programs into terminating ones (such operations\r\nget pushed inside lambdas) but this is consistent with our treatment\r\nof lambdas generally.\r\n\r\nActually, your divInt# call wouldn't even usually be floated out to\r\nbetween two lambdas, but at the time FloatOut runs there is something\r\nin between the \\x lambda and the lambdas from the state monad - the\r\nmonadic bind operator! So FloatOut feels free to move the computation\r\nfor \"x\" up even though that >>= will go away as soon as we run the\r\nsimplifier. What a disaster!\r\n}}}\r\n\r\nSo one of FloatOut and primOpIsCheap probably needs to be fixed.\r\n\r\nI've attached a program that can reproduce this issue.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3035:steplocal and :stepmodule should not polute trace history2019-07-07T19:05:47Zphercek:steplocal and :stepmodule should not polute trace history:steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping.
For some discussion related to this see
http://www.haskell...:steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping.
For some discussion related to this see
http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016576.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":":steplocal and :stepmodule should not polute trace history","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":":steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping.\r\n\r\nFor some discussion related to this see\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016576.html","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3036Max/Min Monoids2019-07-07T19:05:47ZwhpearsonMax/Min MonoidsA small patch to Data.Monoid to give Max a and Min a monoids for (Ord a, Bounded a) = \> a. Very similar to Sum and Product.
Some alternatives here for unbounded Max/Mins
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528
My current pr...A small patch to Data.Monoid to give Max a and Min a monoids for (Ord a, Bounded a) = \> a. Very similar to Sum and Product.
Some alternatives here for unbounded Max/Mins
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528
My current preferred one is to not to bother and perhaps put Data.AddBounds in the main branch and people can wrap Integers in that if they want. It seems conceptually purer.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Max/Min Monoids","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A small patch to Data.Monoid to give Max a and Min a monoids for (Ord a, Bounded a) = > a. Very similar to Sum and Product.\r\n\r\nSome alternatives here for unbounded Max/Mins\r\nhttp://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528\r\n\r\nMy current preferred one is to not to bother and perhaps put Data.AddBounds in the main branch and people can wrap Integers in that if they want. It seems conceptually purer.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3037GHC panics when configuring base2019-07-07T19:05:46ZmooismGHC panics when configuring base```
$ wget http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz
--2009-02-19 19:54:31-- http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz
Resolving hackage.haskell.org... 69.30.63.197
C...```
$ wget http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz
--2009-02-19 19:54:31-- http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz
Resolving hackage.haskell.org... 69.30.63.197
Connecting to hackage.haskell.org|69.30.63.197|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 409339 (400K) [application/x-tar]
Saving to: `base-4.0.0.0.tar.gz'
100%[========================================================================================================>] 409,339 86.7K/s in 5.6s
2009-02-19 19:54:37 (71.8 KB/s) - `base-4.0.0.0.tar.gz' saved [409339/409339]
$ tar zxf base-4.0.0.0.tar.gz
$ cd base-4.0.0.0
$ runhaskell Setup.hs configure
<interactive>:1:22:
attempting to use module `System.IO' (System/IO.hs) which is not loaded
<interactive>:1:22: Not in scope: `System.IO.stderr'
<interactive>:1:22: Not in scope: `System.IO.stdin'
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-linux):
interactiveUI:setBuffering
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I am using Ubuntu 8.10 Linux 2.6.27-11-generic i686.
I am having trouble using cabal-install, and my real problem may lie there, but I thought I should report this anyway.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| 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 panics when configuring base","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":["base,","base-4.0.0.0,","panic!","panic,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\n$ wget http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz\r\n--2009-02-19 19:54:31-- http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz\r\nResolving hackage.haskell.org... 69.30.63.197\r\nConnecting to hackage.haskell.org|69.30.63.197|:80... connected.\r\nHTTP request sent, awaiting response... 200 OK\r\nLength: 409339 (400K) [application/x-tar]\r\nSaving to: `base-4.0.0.0.tar.gz'\r\n\r\n100%[========================================================================================================>] 409,339 86.7K/s in 5.6s \r\n\r\n2009-02-19 19:54:37 (71.8 KB/s) - `base-4.0.0.0.tar.gz' saved [409339/409339]\r\n\r\n$ tar zxf base-4.0.0.0.tar.gz \r\n$ cd base-4.0.0.0\r\n$ runhaskell Setup.hs configure\r\n\r\n<interactive>:1:22:\r\n attempting to use module `System.IO' (System/IO.hs) which is not loaded\r\n\r\n<interactive>:1:22: Not in scope: `System.IO.stderr'\r\n\r\n<interactive>:1:22: Not in scope: `System.IO.stdin'\r\nghc-6.8.2: panic! (the 'impossible' happened)\r\n (GHC version 6.8.2 for i386-unknown-linux):\r\n\tinteractiveUI:setBuffering\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\n}}}\r\n\r\nI am using Ubuntu 8.10 Linux 2.6.27-11-generic i686.\r\n\r\nI am having trouble using cabal-install, and my real problem may lie there, but I thought I should report this anyway.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3038Associated type use triggers a bogus error message2019-07-07T19:05:46ZconalAssociated type use triggers a bogus error messageIn GHCi, version 6.11.20090115 built from HEAD
```
{-# LANGUAGE TypeOperators, TypeFamilies #-}
{-# OPTIONS_GHC -Wall #-}
-- With associate type synonym, the ch' definition leads to
--
-- Couldn't match expected type `Basis u1'
...In GHCi, version 6.11.20090115 built from HEAD
```
{-# LANGUAGE TypeOperators, TypeFamilies #-}
{-# OPTIONS_GHC -Wall #-}
-- With associate type synonym, the ch' definition leads to
--
-- Couldn't match expected type `Basis u1'
-- against inferred type `Basis u'
-- Expected type: u1 :-* v
-- Inferred type: u :-* v
-- In the expression: ch
-- In the definition of `ch'': ch' = ch
--
-- With associated data type, no problem.
class HasBasis u where type Basis u :: *
-- class HasBasis u where data Basis u :: *
type u :-* v = Basis u -> v
ch :: (HasBasis u, HasBasis v) =>
(v :-* w) -> (u :-* v) -> (u :-* w)
ch = undefined
ch' :: (HasBasis u, HasBasis v) =>
(v :-* w) -> (u :-* v) -> (u :-* w)
ch' = ch
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | conal@conal.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Associated type use triggers a bogus error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["associated","synonym","type"],"differentials":[],"test_case":"","architecture":"","cc":["conal@conal.net"],"type":"Bug","description":"In GHCi, version 6.11.20090115 built from HEAD\r\n\r\n{{{\r\n\r\n{-# LANGUAGE TypeOperators, TypeFamilies #-}\r\n{-# OPTIONS_GHC -Wall #-}\r\n\r\n-- With associate type synonym, the ch' definition leads to\r\n-- \r\n-- Couldn't match expected type `Basis u1'\r\n-- against inferred type `Basis u'\r\n-- Expected type: u1 :-* v\r\n-- Inferred type: u :-* v\r\n-- In the expression: ch\r\n-- In the definition of `ch'': ch' = ch\r\n-- \r\n-- With associated data type, no problem.\r\n\r\n\r\nclass HasBasis u where type Basis u :: *\r\n\r\n-- class HasBasis u where data Basis u :: *\r\n\r\n\r\ntype u :-* v = Basis u -> v\r\n\r\nch :: (HasBasis u, HasBasis v) =>\r\n (v :-* w) -> (u :-* v) -> (u :-* w)\r\nch = undefined\r\n\r\nch' :: (HasBasis u, HasBasis v) =>\r\n (v :-* w) -> (u :-* v) -> (u :-* w)\r\nch' = ch\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3039strange space usage2019-07-07T19:05:45ZIan Lynagh <igloo@earth.li>strange space usageThis program:
```
module Main (main) where
import System.IO.Unsafe
main :: IO ()
main = do writeFile "wibbleflibble" (replicate 100 'z')
bs <- getCs $ g $ replicate 1000000 "flibble"
print $ last bs
getCs :: [File...This program:
```
module Main (main) where
import System.IO.Unsafe
main :: IO ()
main = do writeFile "wibbleflibble" (replicate 100 'z')
bs <- getCs $ g $ replicate 1000000 "flibble"
print $ last bs
getCs :: [FilePath] -> IO String
getCs [] = return ""
getCs (c : cs) = do x <- readFile c
xs <- unsafeInterleaveIO $ getCs cs
return (x ++ xs)
g :: [FilePath] -> [FilePath]
g is = map f is
f :: FilePath -> FilePath
f fn = "wibble" ++ fn
```
when run:
```
$ ghc -fforce-recomp -Wall --make -O2 -prof -auto-all z.hs -o z
$ ./z +RTS -h -p
```
shows that around 100k is used by `f` (`h.png`). Running with
```
$ ./z +RTS -hcf -hy -p
```
shows that it is all of type `[]` (`hcf_hy.png`). That seems like a large amount of space for a 13 character filename, so it smells to me like something is wrong somewhere.
If we inline `g`:
```
module Main (main) where
import System.IO.Unsafe
main :: IO ()
main = do writeFile "wibbleflibble" (replicate 100 'z')
bs <- getCs $ map f $ replicate 1000000 "flibble"
print $ last bs
getCs :: [FilePath] -> IO String
getCs [] = return ""
getCs (c : cs) = do x <- readFile c
xs <- unsafeInterleaveIO $ getCs cs
return (x ++ xs)
f :: FilePath -> FilePath
f fn = "wibble" ++ fn
```
then it all disappears (`h2.png`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"strange space usage","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport System.IO.Unsafe\r\n\r\nmain :: IO ()\r\nmain = do writeFile \"wibbleflibble\" (replicate 100 'z')\r\n bs <- getCs $ g $ replicate 1000000 \"flibble\"\r\n print $ last bs\r\n\r\ngetCs :: [FilePath] -> IO String\r\ngetCs [] = return \"\"\r\ngetCs (c : cs) = do x <- readFile c\r\n xs <- unsafeInterleaveIO $ getCs cs\r\n return (x ++ xs)\r\n\r\ng :: [FilePath] -> [FilePath]\r\ng is = map f is\r\n\r\nf :: FilePath -> FilePath \r\nf fn = \"wibble\" ++ fn\r\n}}}\r\nwhen run:\r\n{{{\r\n$ ghc -fforce-recomp -Wall --make -O2 -prof -auto-all z.hs -o z\r\n$ ./z +RTS -h -p\r\n}}}\r\nshows that around 100k is used by `f` (`h.png`). Running with\r\n{{{\r\n$ ./z +RTS -hcf -hy -p\r\n}}}\r\nshows that it is all of type `[]` (`hcf_hy.png`). That seems like a large amount of space for a 13 character filename, so it smells to me like something is wrong somewhere.\r\n\r\nIf we inline `g`:\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport System.IO.Unsafe\r\n\r\nmain :: IO ()\r\nmain = do writeFile \"wibbleflibble\" (replicate 100 'z')\r\n bs <- getCs $ map f $ replicate 1000000 \"flibble\"\r\n print $ last bs\r\n\r\ngetCs :: [FilePath] -> IO String\r\ngetCs [] = return \"\"\r\ngetCs (c : cs) = do x <- readFile c\r\n xs <- unsafeInterleaveIO $ getCs cs\r\n return (x ++ xs)\r\n\r\nf :: FilePath -> FilePath \r\nf fn = \"wibble\" ++ fn\r\n}}}\r\nthen it all disappears (`h2.png`).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3040make clean fails (in utils/hsc2hs?) on 6.102019-07-07T19:05:44Znr@eecs.harvard.edumake clean fails (in utils/hsc2hs?) on 6.10`make clean` halts with an error message. Here's the tail of the output:
```
make -C hpc clean
/home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --dis...`make clean` halts with an error message. Here's the tail of the output:
```
make -C hpc clean
/home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --distpref dist-inplace
cleaning...
/home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --distpref dist-install
cleaning...
rm -f -rf install-inplace
make -C hsc2hs clean
make[2]: *** No rule to make target `clean'. Stop.
make[1]: *** [clean.hsc2hs] Error 2
Failed making clean in utils: 1
make: *** [clean] Error 1
: nr@homedog 2958
```
I ran `darcs-all get` but this left me with an empty utils/hsc2hs directory, which turned out to be the cause of the problem. Removing the empty directory and re-running `darcs-all get` solved the problem. Not sure if this one is likely to recur, but I thought you should know about it. Perhaps ./configure ought to fail if a directory that should be nonempty is found to be empty?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make clean fails (in utils/hsc2hs?) on 6.10","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{make clean}}} halts with an error message. Here's the tail of the output:\r\n\r\n{{{\r\nmake -C hpc clean\r\n/home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --distpref dist-inplace\r\ncleaning...\r\n/home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --distpref dist-install\r\ncleaning...\r\nrm -f -rf install-inplace\r\nmake -C hsc2hs clean\r\nmake[2]: *** No rule to make target `clean'. Stop.\r\nmake[1]: *** [clean.hsc2hs] Error 2\r\nFailed making clean in utils: 1\r\nmake: *** [clean] Error 1\r\n: nr@homedog 2958 \r\n}}}\r\n\r\nI ran {{{darcs-all get}}} but this left me with an empty utils/hsc2hs directory, which turned out to be the cause of the problem. Removing the empty directory and re-running {{{darcs-all get}}} solved the problem. Not sure if this one is likely to recur, but I thought you should know about it. Perhaps ./configure ought to fail if a directory that should be nonempty is found to be empty?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3041Arch independent binary representations2019-07-07T19:05:42ZJoachim Breitnermail@joachim-breitner.deArch independent binary representationsHi,
when packaging ghc6.10 for Debian, we stumbled over a rather large annoyance: Haddock’s .haddock files are not architecture independent any more. It uses Binary instances to serialize it’s data, and for Int, the size depends on the ...Hi,
when packaging ghc6.10 for Debian, we stumbled over a rather large annoyance: Haddock’s .haddock files are not architecture independent any more. It uses Binary instances to serialize it’s data, and for Int, the size depends on the architecture it is running. As otherwise the .haddock files should not be arch independent, it would make life for the ghc6 maintainer easier if this can be changed.
I started to fix haddock there, but it uses the Binary instance for some of ghc6 internal structures (Name at least, maybe more), which also serialize Int’s without specifying the size.
Would it be accepted to change the Binary instances for (at least) these data types to convert all Int’s to Int32’s or Int64’s before serialization? What would be broken by such a change?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | debian-haskell@lists.debian.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Arch independent binary representations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["debian-haskell@lists.debian.org"],"type":"FeatureRequest","description":"Hi,\r\n\r\nwhen packaging ghc6.10 for Debian, we stumbled over a rather large annoyance: Haddock’s .haddock files are not architecture independent any more. It uses Binary instances to serialize it’s data, and for Int, the size depends on the architecture it is running. As otherwise the .haddock files should not be arch independent, it would make life for the ghc6 maintainer easier if this can be changed.\r\n\r\nI started to fix haddock there, but it uses the Binary instance for some of ghc6 internal structures (Name at least, maybe more), which also serialize Int’s without specifying the size.\r\n\r\nWould it be accepted to change the Binary instances for (at least) these data types to convert all Int’s to Int32’s or Int64’s before serialization? What would be broken by such a change?","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3042rts defines "real_main" which can clash with user C code2019-07-07T19:05:41Zduncanrts defines "real_main" which can clash with user C codeI was just about to file a bug about `ghc -no-hs-main` not working but it turns out it is just because I had a `real_main` C function in my `.c` file. This ends up clashing with the C function of the same name from the rts package. This ...I was just about to file a bug about `ghc -no-hs-main` not working but it turns out it is just because I had a `real_main` C function in my `.c` file. This ends up clashing with the C function of the same name from the rts package. This means that when linking we pull in the wrong one and the rts one needs `__stginit_ZCMain` and `ZCMain_main_closure` which is what the linker error message reports (which is rather confusing).
Suggestion: rename the rts `real_main` to something less likely to clash with user code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"rts defines \"real_main\" which can clash with user C code","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was just about to file a bug about `ghc -no-hs-main` not working but it turns out it is just because I had a `real_main` C function in my `.c` file. This ends up clashing with the C function of the same name from the rts package. This means that when linking we pull in the wrong one and the rts one needs `__stginit_ZCMain` and `ZCMain_main_closure` which is what the linker error message reports (which is rather confusing).\r\n\r\nSuggestion: rename the rts `real_main` to something less likely to clash with user code.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3043An unrelated definition monomorphizes a type even without the MR2019-07-07T19:05:41ZDeewiantAn unrelated definition monomorphizes a type even without the MRThe following code:
```
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FunctionalDependencies #-}
class Id a b | b -> a where id' :: a -> b
instance Id [Char] [Char] where id' = id
cl...The following code:
```
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FunctionalDependencies #-}
class Id a b | b -> a where id' :: a -> b
instance Id [Char] [Char] where id' = id
class Fst a where fst' :: a -> String
instance Fst ([Char],a) where fst' = fst
data Void a = Void
void :: (String,a) -> Void a
void _ = Void
fst'' (a,b) =
let x = (id' a, b)
y = void x :: Void Int -- remove this line and the code compiles
in fst' x
```
Results in:
```
arst.hs:18:6:
No instance for (Fst (b, Int))
arising from a use of `fst'' at arst.hs:18:6-11
Possible fix: add an instance declaration for (Fst (b, Int))
In the expression: fst' x
In the expression:
let
x = (id' a, b)
y = void x :: Void Int
in fst' x
In the definition of `fst''':
fst'' (a, b)
= let
x = ...
y = ...
in fst' x
arst.hs:18:11:
No instance for (Id [Char] b)
arising from a use of `x' at arst.hs:18:11
Possible fix: add an instance declaration for (Id [Char] b)
In the first argument of `fst'', namely `x'
In the expression: fst' x
In the expression:
let
x = (id' a, b)
y = void x :: Void Int
in fst' x
```
It seems that the definition of `y` locks down the type of `x` somewhat even though the monomorphism restriction is disabled. If we remove the definition:
```
*Main> :t fst''
fst'' :: (Id t b, Fst (b, t1)) => (t, t1) -> String
```
To be completely honest I'm not sure whether the code should be accepted or not, since `(Id t b, Fst (b, t1))` can't be satisfied. Only the fully monomorphic signature `([Char], Int) -> String`, which is obtained with the definition of `y` in place and the monomorphism restriction enabled, works.
In any case, I think it's a bug that the results of the type check depend on whether `y` is defined or not: surely that shouldn't matter at all, no matter what the end result is.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"An unrelated definition monomorphizes a type even without the MR","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code:\r\n{{{\r\n{-# LANGUAGE NoMonomorphismRestriction #-}\r\n{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FunctionalDependencies #-}\r\n\r\nclass Id a b | b -> a where id' :: a -> b\r\ninstance Id [Char] [Char] where id' = id\r\n\r\nclass Fst a where fst' :: a -> String\r\ninstance Fst ([Char],a) where fst' = fst\r\n\r\ndata Void a = Void\r\n\r\nvoid :: (String,a) -> Void a\r\nvoid _ = Void\r\n\r\nfst'' (a,b) =\r\n let x = (id' a, b)\r\n y = void x :: Void Int -- remove this line and the code compiles\r\n in fst' x\r\n}}}\r\nResults in:\r\n{{{\r\narst.hs:18:6:\r\n No instance for (Fst (b, Int))\r\n arising from a use of `fst'' at arst.hs:18:6-11\r\n Possible fix: add an instance declaration for (Fst (b, Int))\r\n In the expression: fst' x\r\n In the expression:\r\n let\r\n x = (id' a, b)\r\n y = void x :: Void Int\r\n in fst' x\r\n In the definition of `fst''':\r\n fst'' (a, b)\r\n = let\r\n x = ...\r\n y = ...\r\n in fst' x\r\n\r\narst.hs:18:11:\r\n No instance for (Id [Char] b)\r\n arising from a use of `x' at arst.hs:18:11\r\n Possible fix: add an instance declaration for (Id [Char] b)\r\n In the first argument of `fst'', namely `x'\r\n In the expression: fst' x\r\n In the expression:\r\n let\r\n x = (id' a, b)\r\n y = void x :: Void Int\r\n in fst' x\r\n}}}\r\n\r\nIt seems that the definition of `y` locks down the type of `x` somewhat even though the monomorphism restriction is disabled. If we remove the definition:\r\n{{{\r\n*Main> :t fst''\r\nfst'' :: (Id t b, Fst (b, t1)) => (t, t1) -> String\r\n}}}\r\n\r\nTo be completely honest I'm not sure whether the code should be accepted or not, since `(Id t b, Fst (b, t1))` can't be satisfied. Only the fully monomorphic signature `([Char], Int) -> String`, which is obtained with the definition of `y` in place and the monomorphism restriction enabled, works.\r\n\r\nIn any case, I think it's a bug that the results of the type check depend on whether `y` is defined or not: surely that shouldn't matter at all, no matter what the end result is.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3044NoImplicitPrelude being ignored by 6.10.1, works in 6.8.22019-07-07T19:05:40Ziampure@gmail.comNoImplicitPrelude being ignored by 6.10.1, works in 6.8.2\~/bin/ghci -XNoImplicitPrelude Main.hs results in the module being loaded
Expected result: the module should fail saying that putStrLn cannot be found/is not in scope.
```
module Main where
import Foo
import qualified Prelude as P
mai...\~/bin/ghci -XNoImplicitPrelude Main.hs results in the module being loaded
Expected result: the module should fail saying that putStrLn cannot be found/is not in scope.
```
module Main where
import Foo
import qualified Prelude as P
main = P.putStrLn []
```
```
module Foo where
zork = putStrLn "hi"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"~/bin/ghci -XNoImplicitPrelude Main.hs results in the module being loaded\r\n\r\nExpected result: the module should fail saying that putStrLn cannot be found/is not in scope. \r\n\r\n{{{\r\nmodule Main where\r\nimport Foo\r\nimport qualified Prelude as P\r\nmain = P.putStrLn []\r\n}}}\r\n\r\n{{{\r\nmodule Foo where\r\nzork = putStrLn \"hi\"\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3045GHCI Crashes Under Windows when loading compiled code2019-07-07T19:05:40ZjburckGHCI Crashes Under Windows when loading compiled codewhenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
loadObj: failed
<details><summary>Trac metadata</summary>
...whenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
loadObj: failed
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCI Crashes Under Windows when loading compiled code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"whenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened) \r\n\r\n(GHC version 6.10.1 for i386-unknown-mingw32): \r\n\r\nloadObj: failed \r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3046Generalized newtype deriving with associated types2019-07-07T19:05:39ZLouisWassermanGeneralized newtype deriving with associated typesWhen I have a
```
class Foo a where
type Bar a
foobar :: a -> Bar a
```
an
```
instance Foo Fooey ...
```
and
```
newtype Fooey2 = F2 (Fooey) deriving (Foo)
```
I expect the automatically generated deriving to include
```
t...When I have a
```
class Foo a where
type Bar a
foobar :: a -> Bar a
```
an
```
instance Foo Fooey ...
```
and
```
newtype Fooey2 = F2 (Fooey) deriving (Foo)
```
I expect the automatically generated deriving to include
```
type Bar Fooey2 = Bar Fooey
```
but this is not the case: I cannot get an associated type from a newtype to resolve to anything. My guess is that the combination of -XTypeFamilies and -XGeneralizedNewtypeDeriving is rare enough that this may simply not have been thought of yet, but it's something I'd like to see fixed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Generalized newtype deriving with associated types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I have a\r\n\r\n\r\n{{{\r\n class Foo a where\r\n\ttype Bar a\r\n\tfoobar :: a -> Bar a\r\n}}}\r\n\r\nan \r\n{{{\r\ninstance Foo Fooey ...\r\n}}}\r\n\r\nand\r\n\r\n{{{\r\nnewtype Fooey2 = F2 (Fooey) deriving (Foo) \r\n}}}\r\n\r\nI expect the automatically generated deriving to include\r\n\r\n\r\n{{{\r\ntype Bar Fooey2 = Bar Fooey\r\n}}}\r\n\r\nbut this is not the case: I cannot get an associated type from a newtype to resolve to anything. My guess is that the combination of -XTypeFamilies and -XGeneralizedNewtypeDeriving is rare enough that this may simply not have been thought of yet, but it's something I'd like to see fixed.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3047Panic! (the 'impossible' happened) :)2019-07-07T19:05:39ZbchallenorPanic! (the 'impossible' happened) :)I was just coding up a solution to a Project Euler problem when the following occurred. I'm attaching the source file. It should be useful as it's very short (well, except for there being a 46KB list on one line).
I apologize if this is...I was just coding up a solution to a Project Euler problem when the following occurred. I'm attaching the source file. It should be useful as it's very short (well, except for there being a 46KB list on one line).
I apologize if this is a duplicate, because I'm using a fairly old GHCi.
Cheers
Ben
\[1 of 1\] Compiling Main ( C:/Users/Ben/Desktop/ProjectEuler/22.hs, i
nterpreted )
: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-mingw32):
> linkBCO: \>= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| 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":"Panic! (the 'impossible' happened) :)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was just coding up a solution to a Project Euler problem when the following occurred. I'm attaching the source file. It should be useful as it's very short (well, except for there being a 46KB list on one line).\r\n\r\nI apologize if this is a duplicate, because I'm using a fairly old GHCi.\r\n\r\nCheers\r\nBen\r\n\r\n\r\n[1 of 1] Compiling Main ( C:/Users/Ben/Desktop/ProjectEuler/22.hs, i\r\nnterpreted )\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.8.2 for i386-unknown-mingw32):\r\n linkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3048Heap size suggestion gets ignored when -G1 flag is passed2019-07-07T19:05:39Zchevalier@alum.wellesley.eduHeap size suggestion gets ignored when -G1 flag is passedTry running any program with `-G1` and a large `-H` option -- for example, cichelli from the nofib suite:
```
$ ./cichelli +RTS -s -H32M -G1
[output snipped]
41,211,752 bytes allocated in the heap
19,329,984 bytes copied during G...Try running any program with `-G1` and a large `-H` option -- for example, cichelli from the nofib suite:
```
$ ./cichelli +RTS -s -H32M -G1
[output snipped]
41,211,752 bytes allocated in the heap
19,329,984 bytes copied during GC
1,760,916 bytes maximum residency (34 sample(s))
36,724 bytes maximum slop
7 MB total memory in use (0 MB lost due to fragmentation)
```
Here, the suggestion of 32M seems to have been ignored, as the heap is at most 7M during execution. Whereas without `-G1`:
```
./cichelli +RTS -s -H32M
[output snipped]
41,212,300 bytes allocated in the heap
1,121,304 bytes copied during GC
49,484 bytes maximum residency (1 sample(s))
36,824 bytes maximum slop
31 MB total memory in use (0 MB lost due to fragmentation)
```
Here, the size suggestion is used and a 32M heap is allocated.
Shouldn't the GC use the heap size suggestion even when there is only one generation?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Heap size suggestion gets ignored when -G1 flag is passed","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Try running any program with {{{-G1}}} and a large {{{-H}}} option -- for example, cichelli from the nofib suite:\r\n{{{\r\n$ ./cichelli +RTS -s -H32M -G1\r\n[output snipped]\r\n41,211,752 bytes allocated in the heap\r\n 19,329,984 bytes copied during GC\r\n 1,760,916 bytes maximum residency (34 sample(s))\r\n 36,724 bytes maximum slop\r\n 7 MB total memory in use (0 MB lost due to fragmentation)\r\n}}}\r\n\r\nHere, the suggestion of 32M seems to have been ignored, as the heap is at most 7M during execution. Whereas without {{{-G1}}}:\r\n{{{\r\n./cichelli +RTS -s -H32M\r\n[output snipped]\r\n41,212,300 bytes allocated in the heap\r\n 1,121,304 bytes copied during GC\r\n 49,484 bytes maximum residency (1 sample(s))\r\n 36,824 bytes maximum slop\r\n 31 MB total memory in use (0 MB lost due to fragmentation)\r\n}}}\r\n\r\nHere, the size suggestion is used and a 32M heap is allocated.\r\n\r\nShouldn't the GC use the heap size suggestion even when there is only one generation?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3049STM with data invariants crashes GHC2019-07-07T19:05:39ZSimon Peyton JonesSTM with data invariants crashes GHCBen Franksen writes: my ghc(i) crashes when using STM data invariants. This little piece of code demonstrates the problem:
```
module Bug where
import Control.Concurrent.STM
test = do
x <- atomically $ do
v <- newTVar 0
alwa...Ben Franksen writes: my ghc(i) crashes when using STM data invariants. This little piece of code demonstrates the problem:
```
module Bug where
import Control.Concurrent.STM
test = do
x <- atomically $ do
v <- newTVar 0
always $ return True -- remove this line and all is fine
return v
atomically (readTVar x) >>= print
```
This is what ghci makes of it:
```
ben@sarun> ghci Bug.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, modules loaded: Bug.
*Bug> test
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package stm-2.1.1.2 ... linking ... done.
zsh: segmentation fault ghci Bug.hs
```
I am using ghc-6.10.1 freshly installed from source with just a 'cabal
install stm' thrown after it.
BTW, the documentation for `Control.Concurrent.STM.TVar` lists... nothing.
Similar with `Control.Monad.STM`. Well, at least the source link works, so
one isn't completely lost... :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ben.franksen@online.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"STM with data invariants crashes GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ben.franksen@online.de"],"type":"Bug","description":"Ben Franksen writes: my ghc(i) crashes when using STM data invariants. This little piece of code demonstrates the problem:\r\n{{{\r\nmodule Bug where\r\n\r\nimport Control.Concurrent.STM\r\n\r\ntest = do\r\n x <- atomically $ do\r\n v <- newTVar 0\r\n always $ return True -- remove this line and all is fine\r\n return v\r\n atomically (readTVar x) >>= print\r\n}}}\r\nThis is what ghci makes of it:\r\n{{{\r\nben@sarun> ghci Bug.hs\r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, modules loaded: Bug.\r\n*Bug> test\r\nLoading package syb ... linking ... done.\r\nLoading package array-0.2.0.0 ... linking ... done.\r\nLoading package stm-2.1.1.2 ... linking ... done.\r\nzsh: segmentation fault ghci Bug.hs\r\n}}}\r\nI am using ghc-6.10.1 freshly installed from source with just a 'cabal\r\ninstall stm' thrown after it.\r\n\r\nBTW, the documentation for `Control.Concurrent.STM.TVar` lists... nothing.\r\nSimilar with `Control.Monad.STM`. Well, at least the source link works, so\r\none isn't completely lost... :-)\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3050parsec: bug in caret escape parsing2019-07-07T19:05:39Zsofparsec: bug in caret escape parsingThe parsing of escape carets in character literals isn't quite right:
- off-by-one (i.e., \\\^A == \\NUL; ought to be \\\^A=\\001)
- only A-Z carets are supported.
The following minor mod takes care of the problem:
```
--- Text/Parser...The parsing of escape carets in character literals isn't quite right:
- off-by-one (i.e., \\\^A == \\NUL; ought to be \\\^A=\\001)
- only A-Z carets are supported.
The following minor mod takes care of the problem:
```
--- Text/ParserCombinators/Parsec/Token.hs 2009-02-20 10:49:32.115500000 -0800
+++ Text/ParserCombinators/Parsec/Token.hs.~1~ 2009-02-20 10:02:45.896750000 -0800
@@ -193,8 +193,8 @@
-- charControl :: CharParser st Char
charControl = do{ char '^'
- ; code <- (oneOf ['@'..'_']) <|> char '?'
- ; return (if code == '?' then '\DEL' else toEnum (fromEnum code - fromEnum '@'))
+ ; code <- upper
+ ; return (toEnum (fromEnum code - fromEnum 'A'))
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sof |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"parsec: bug in caret escape parsing","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sof"],"type":"Bug","description":"The parsing of escape carets in character literals isn't quite right:\r\n * off-by-one (i.e., \\^A == \\NUL; ought to be \\^A=\\001)\r\n * only A-Z carets are supported.\r\n\r\nThe following minor mod takes care of the problem:\r\n\r\n{{{\r\n--- Text/ParserCombinators/Parsec/Token.hs\t2009-02-20 10:49:32.115500000 -0800\r\n+++ Text/ParserCombinators/Parsec/Token.hs.~1~\t2009-02-20 10:02:45.896750000 -0800\r\n@@ -193,8 +193,8 @@\r\n \r\n -- charControl :: CharParser st Char\r\n charControl = do{ char '^'\r\n- ; code <- (oneOf ['@'..'_']) <|> char '?'\r\n- ; return (if code == '?' then '\\DEL' else toEnum (fromEnum code - fromEnum '@'))\r\n+ ; code <- upper\r\n+ ; return (toEnum (fromEnum code - fromEnum 'A'))\r\n }\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3051Add product/sum/maximum/minimum specialisations for more atomic types2019-07-07T19:05:38ZthorkilnaurAdd product/sum/maximum/minimum specialisations for more atomic typesQuoting dons (http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016707.html):
1. .. product/sum/maximum/minimum
on lists have specialisations for some atomic types (Int, Integer) but
> not all (needs a ticket for th...Quoting dons (http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016707.html):
1. .. product/sum/maximum/minimum
on lists have specialisations for some atomic types (Int, Integer) but
> not all (needs a ticket for this too).
So here is that ticket, just to help us remember.
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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 product/sum/maximum/minimum specialisations for more atomic types","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Quoting dons (http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016707.html):\r\n\r\n ... product/sum/maximum/minimum\r\n on lists have specialisations for some atomic types (Int, Integer) but\r\n not all (needs a ticket for this too).\r\n\r\nSo here is that ticket, just to help us remember.\r\n\r\nBest regards\r\nThorkil","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3052ghc FFI doesn't support thiscall2021-07-12T19:17:14Zlennart@augustsson.netghc FFI doesn't support thiscallThe ghc FFI does not support the "thiscall" calling convention.
This is the calling convention used by Microsoft C++ for calling methods.
It's like the stdcall calling convention, except that the "this" pointer is passed in ECX.
Without...The ghc FFI does not support the "thiscall" calling convention.
This is the calling convention used by Microsoft C++ for calling methods.
It's like the stdcall calling convention, except that the "this" pointer is passed in ECX.
Without this calling convention it's impossible to interact with (Msft) C++ objects.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc FFI doesn't support thiscall","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"The ghc FFI does not support the \"thiscall\" calling convention.\r\nThis is the calling convention used by Microsoft C++ for calling methods.\r\nIt's like the stdcall calling convention, except that the \"this\" pointer is passed in ECX.\r\n\r\nWithout this calling convention it's impossible to interact with (Msft) C++ objects.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3053Modular arithmetic bug?2019-07-07T19:05:38ZvlaadModular arithmetic bug?GHC dies here (please note the x \< 200 limit):
take 15 \[x \| x \<- \[1..\], x \< 200, x `mod` 6 == 1, x `mod` 6 == 5\]
And here (nothing with infix notation):
take 15 \[x \| x \<- \[1..\], x \< 200, mod x 6 == 1, mod x 6 == 5\]
But...GHC dies here (please note the x \< 200 limit):
take 15 \[x \| x \<- \[1..\], x \< 200, x `mod` 6 == 1, x `mod` 6 == 5\]
And here (nothing with infix notation):
take 15 \[x \| x \<- \[1..\], x \< 200, mod x 6 == 1, mod x 6 == 5\]
But \*not\* here:
take 15 \[x \| x \<- \[1..\], mod x 6 == 1, x \< 200, x \> 100\]
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Modular arithmetic bug?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC dies here (please note the x < 200 limit):\r\n take 15 [x | x <- [1..], x < 200, x `mod` 6 == 1, x `mod` 6 == 5]\r\n\r\nAnd here (nothing with infix notation):\r\n take 15 [x | x <- [1..], x < 200, mod x 6 == 1, mod x 6 == 5]\r\n\r\nBut *not* here:\r\n take 15 [x | x <- [1..], mod x 6 == 1, x < 200, x > 100]\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3054ghc crashes with unicode escape and literal character together2019-07-07T19:05:38Ziamfishheadghc crashes with unicode escape and literal character togetherOn debian testing, ghc panics on the atached file. The file simply has a unicode character escape followed by the character itself.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -----------------...On debian testing, ghc panics on the atached file. The file simply has a unicode character escape followed by the character itself.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| 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 crashes with unicode escape and literal character together","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On debian testing, ghc panics on the atached file. The file simply has a unicode character escape followed by the character itself.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3055Int / Word / IntN / WordN are unequally optimized2019-07-07T19:05:37Zclaus.reinke@talk21.comInt / Word / IntN / WordN are unequally optimizedA lot of thought has been put into optimizing usage of `Int`, but not all of these tweaks have been copied for usage of `Word`, and the specific-size versions of both have even fewer optimizations. The consequence is that switching from ...A lot of thought has been put into optimizing usage of `Int`, but not all of these tweaks have been copied for usage of `Word`, and the specific-size versions of both have even fewer optimizations. The consequence is that switching from signed to unsigned, or from unspecified to specified size, can result in dramatic performance loss.
- builtin rules (`prelude/PrelRules`) cover `Int` and `Word`, but not sized alternatives
- `SPECIALI[SZ]E` pragmas cover `Int`, but little of the others. Try
```
find libraries/ -name _darcs -prune -o -name *hs |
xargs grep SPECIAL | grep '\<Int\|\<Word'
```
- some instances have special cases for `Int`, but not for the others (for instance, the `Enum` instance for `Int` uses specialised `enumFromTo` code, the `Word` version uses generic code; `base/GHC/Enum.hs` and `base/GHC/Word.hs`)
- some `RULES` help optimizing the special cases for `Int` further (again, see the `Enum` instance for `Int` for an example)
See this thread ["Int vs Word performance?"](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016705.html) for more discussion.
related tickets: #2270, #3051
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Int / Word / IntN / WordN are unequally optimized","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A lot of thought has been put into optimizing usage of `Int`, but not all of these tweaks have been copied for usage of `Word`, and the specific-size versions of both have even fewer optimizations. The consequence is that switching from signed to unsigned, or from unspecified to specified size, can result in dramatic performance loss.\r\n\r\n- builtin rules (`prelude/PrelRules`) cover `Int` and `Word`, but not sized alternatives\r\n\r\n- `SPECIALI[SZ]E` pragmas cover `Int`, but little of the others. Try \r\n{{{\r\nfind libraries/ -name _darcs -prune -o -name *hs | \r\n xargs grep SPECIAL | grep '\\<Int\\|\\<Word'\r\n}}}\r\n\r\n- some instances have special cases for `Int`, but not for the others (for instance, the `Enum` instance for `Int` uses specialised `enumFromTo` code, the `Word` version uses generic code; `base/GHC/Enum.hs` and `base/GHC/Word.hs`)\r\n\r\n- some `RULES` help optimizing the special cases for `Int` further (again, see the `Enum` instance for `Int` for an example)\r\n\r\nSee this thread [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016705.html \"Int vs Word performance?\"] for more discussion.\r\n\r\nrelated tickets: #2270, #3051","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3056StrictAnal module naming issue2019-07-07T19:05:37ZpumpkinStrictAnal module naming issueI've been debating submitting this ticket for a couple of days because it may just make me look immature, but it seems like a strange way to abbreviate Strictness Analysis.
The file I'm talking about is:
compiler/stranal/StrictAnal.lhs...I've been debating submitting this ticket for a couple of days because it may just make me look immature, but it seems like a strange way to abbreviate Strictness Analysis.
The file I'm talking about is:
compiler/stranal/StrictAnal.lhs
Maybe this could/should be changed just for aesthetic reasons?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"StrictAnal module naming issue","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've been debating submitting this ticket for a couple of days because it may just make me look immature, but it seems like a strange way to abbreviate Strictness Analysis.\r\n\r\nThe file I'm talking about is:\r\n\r\ncompiler/stranal/StrictAnal.lhs\r\n\r\nMaybe this could/should be changed just for aesthetic reasons?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3057Standalone deriving of Functor does not work for HsDoc2019-07-07T19:05:37ZwaernStandalone deriving of Functor does not work for HsDocI tried to use the new `DerivingFunctor` extension to derive `Functor` for the `HsDoc` type from the ghc package:
```
{-# StandaloneDeriving, DerivingFunctor #-}
import HsDoc
deriving instance Functor HsDoc
```
But I got this error m...I tried to use the new `DerivingFunctor` extension to derive `Functor` for the `HsDoc` type from the ghc package:
```
{-# StandaloneDeriving, DerivingFunctor #-}
import HsDoc
deriving instance Functor HsDoc
```
But I got this error message:
```
david@david-laptop:~/dev/test$ /home/david/ghc-head/bin/ghc --make Test.hs -package ghc
[1 of 1] Compiling Test ( Test.hs, Test.o )
Test.hs:9:0:
Couldn't match expected type `b' against inferred type `a'
`b' is a rigid type variable bound by
the type signature for `fmap' at <no location info>
`a' is a rigid type variable bound by
the type signature for `fmap' at <no location info>
Expected type: HsDoc b
Inferred type: HsDoc a
In the first argument of `DocAppend', namely `a1'
In the expression: DocAppend a1 a2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Standalone deriving of Functor does not work for HsDoc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to use the new `DerivingFunctor` extension to derive `Functor` for the `HsDoc` type from the ghc package:\r\n{{{\r\n{-# StandaloneDeriving, DerivingFunctor #-}\r\n\r\nimport HsDoc\r\n\r\nderiving instance Functor HsDoc\r\n}}}\r\n\r\nBut I got this error message:\r\n{{{\r\ndavid@david-laptop:~/dev/test$ /home/david/ghc-head/bin/ghc --make Test.hs -package ghc\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\n\r\nTest.hs:9:0:\r\n Couldn't match expected type `b' against inferred type `a'\r\n `b' is a rigid type variable bound by\r\n the type signature for `fmap' at <no location info>\r\n `a' is a rigid type variable bound by\r\n the type signature for `fmap' at <no location info>\r\n Expected type: HsDoc b\r\n Inferred type: HsDoc a\r\n In the first argument of `DocAppend', namely `a1'\r\n In the expression: DocAppend a1 a2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3058Add a 'hex' function to the pretty printing2019-07-07T19:05:37ZThomas Main DuBuissonAdd a 'hex' function to the pretty printingAttached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers.
The only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to contr...Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers.
The only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to control the number of characters printed (see below).
> hex 5 31
0001f
> hex 2 8
08
> hex 3 7495
d47
While we can argue about the consistancy issues, I almost always want to control the number of digits when I'm dealing with hex. Hence I feel this is a reasonable special case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| 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 a 'hex' function to the pretty printing","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["library","pretty,","prettyprint,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers.\r\n\r\nThe only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to control the number of characters printed (see below).\r\n\r\n> hex 5 31\r\n0001f\r\n> hex 2 8\r\n08\r\n> hex 3 7495\r\nd47\r\n\r\nWhile we can argue about the consistancy issues, I almost always want to control the number of digits when I'm dealing with hex. Hence I feel this is a reasonable special case.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/30593 different behaviours depending on profiling settings and on a used-only-onc...2019-07-07T19:05:36Zjkff3 different behaviours depending on profiling settings and on a used-only-once form being top-levelBelow are two versions of a program using regex-tdfa-1.0.
The versions differ in whether a form that is used exactly once in 'main' is top-level or declared inside 'where' in main.
Both versions are compiled with/without profiling and th...Below are two versions of a program using regex-tdfa-1.0.
The versions differ in whether a form that is used exactly once in 'main' is top-level or declared inside 'where' in main.
Both versions are compiled with/without profiling and the profiled version is called with/without +RTS -p.
I obtain three drastically different performance results and, in the case where the form is top-level and profiling is turned on, a compilation bug is clearly seen.
```
module Main where
import Text.Regex.TDFA
import qualified Data.ByteString.Lazy.Char8 as L
import qualified Data.ByteString.Char8 as S
main = putStrLn . show . length . filter (pat . S.concat . L.toChunks) . replicate 100000 $ L.pack "Hello world foo=123 whereas bar=456 Goodbye"
pat = (=~ ".*foo=([0-9]+).*bar=([0-9]+).*")
ghc -O2 --make regex-test.hs
./regex-test +RTS -s
0.00s
ghc -O2 --make -prof -auto-all regex-test.hs
./regex-test +RTS -s
265.31s
./regex-test +RTS -p
276.84s
'compile' is called 100000 times.
module Main where
import Text.Regex.TDFA
import qualified Data.ByteString.Lazy.Char8 as L
import qualified Data.ByteString.Char8 as S
main = putStrLn . show . length . filter (pat . S.concat . L.toChunks) . replicate 100000 $ L.pack "Hello world foo=123 whereas bar=456 Goodbye"
where pat = (=~ ".*foo=([0-9]+).*bar=([0-9]+).*")
ghc -O2 --make regex-test.hs
./regex-test +RTS -s
8.86s
(I don't know how this result appeared: it is too small to result from 1mln regex compilations, but too big to be 'normal')
ghc -O2 --make -prof -auto-all regex-test.hs
./regex-test +RTS -s
0.00s
./regex-test +RTS -p
0.00s
'compile' is called 2 times.
```
Core for the first program with/without profiling differs in the aspect that with profiling, the partial application (=\~) does not get memoized.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"3 different behaviours depending on profiling settings and on a used-only-once form being top-level","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Below are two versions of a program using regex-tdfa-1.0.\r\nThe versions differ in whether a form that is used exactly once in 'main' is top-level or declared inside 'where' in main.\r\nBoth versions are compiled with/without profiling and the profiled version is called with/without +RTS -p.\r\nI obtain three drastically different performance results and, in the case where the form is top-level and profiling is turned on, a compilation bug is clearly seen.\r\n{{{\r\nmodule Main where\r\n\r\nimport Text.Regex.TDFA\r\nimport qualified Data.ByteString.Lazy.Char8 as L\r\nimport qualified Data.ByteString.Char8 as S\r\n\r\n\r\nmain = putStrLn . show . length . filter (pat . S.concat . L.toChunks) . replicate 100000 $ L.pack \"Hello world foo=123 whereas bar=456 Goodbye\"\r\n\r\npat = (=~ \".*foo=([0-9]+).*bar=([0-9]+).*\")\r\n\r\n\r\nghc -O2 --make regex-test.hs\r\n./regex-test +RTS -s\r\n0.00s\r\n\r\nghc -O2 --make -prof -auto-all regex-test.hs\r\n./regex-test +RTS -s\r\n265.31s\r\n\r\n./regex-test +RTS -p\r\n276.84s\r\n'compile' is called 100000 times. \r\n\r\n\r\n\r\nmodule Main where\r\n\r\nimport Text.Regex.TDFA\r\nimport qualified Data.ByteString.Lazy.Char8 as L\r\nimport qualified Data.ByteString.Char8 as S\r\n\r\n\r\nmain = putStrLn . show . length . filter (pat . S.concat . L.toChunks) . replicate 100000 $ L.pack \"Hello world foo=123 whereas bar=456 Goodbye\"\r\n where pat = (=~ \".*foo=([0-9]+).*bar=([0-9]+).*\")\r\n\r\n\r\nghc -O2 --make regex-test.hs\r\n./regex-test +RTS -s\r\n8.86s\r\n\r\n(I don't know how this result appeared: it is too small to result from 1mln regex compilations, but too big to be 'normal')\r\n\r\nghc -O2 --make -prof -auto-all regex-test.hs\r\n./regex-test +RTS -s\r\n0.00s\r\n\r\n./regex-test +RTS -p\r\n0.00s\r\n'compile' is called 2 times.\r\n}}}\r\n\r\nCore for the first program with/without profiling differs in the aspect that with profiling, the partial application (=~) does not get memoized.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3060impossible internal bug while building darcs2019-07-07T19:05:36Zkquickimpossible internal bug while building darcs```
[ghc] src/Exec.o
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
applyTypeToArgs
unix-2.3.1.0:System.Posix.Signals.a38{v r8P} [gid]
(unix-2.3.1.0:System.Posix.Signals.a5{v r8O}...```
[ghc] src/Exec.o
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
applyTypeToArgs
unix-2.3.1.0:System.Posix.Signals.a38{v r8P} [gid]
(unix-2.3.1.0:System.Posix.Signals.a5{v r8O} [gid]
`cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v}
base:Foreign.C.Types.:CoCInt{tc r4P}
:: <pred>base:GHC.Int.Int32{tc 3V}
~
<nt>base:Foreign.C.Types.CInt{tc r4S}))
unix-2.3.1.0:System.Posix.Signals.Ignore{v r8N} [gid]
(base:Data.Maybe.Nothing{v r4K} [gid]
@ <nt>unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M})
eta{v a1Vy} [lid]
(# ghc-prim:GHC.Prim.State#{(w) tc 32q}
ghc-prim:GHC.Prim.RealWorld{(w) tc 31E},
<nt>unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M} #)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
While building darcs 2.2.0.https://gitlab.haskell.org/ghc/ghc/-/issues/3061GHC's GC default heap growth strategy is not as good as other runtimes2019-07-07T19:05:35ZdonsGHC's GC default heap growth strategy is not as good as other runtimesThis is a GC performance ticket. The benchmark is the binary-trees benchmark, and the issue is whether or not GHC's ability to grow the heap without a heap check is comparably worse than other similar language runtimes.
Looking at the b...This is a GC performance ticket. The benchmark is the binary-trees benchmark, and the issue is whether or not GHC's ability to grow the heap without a heap check is comparably worse than other similar language runtimes.
Looking at the binary-trees benchmark, we see that GHC does very well on a parallel system, when we give a GC hint to the size.
E.g. the attached binary-trees program is very very competitive:
Compile with:
```
ghc -O2 -fasm --make -threaded A.hs
```
Run with:
```
$ /A 20 +RTS -N4 -H340M
```
And we get:
```
$ time ./A +RTS -N4 -H340M -RTS 20
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
./A +RTS -N4 -H340M -RTS 20 17.08s user 0.30s system 315% cpu 5.511 total
```
However, without that GC hint performance deteriorates dramatically,
```
$ time ./A +RTS -N4 -RTS 20
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
./A +RTS -N4 -RTS 20 33.83s user 0.42s system 136% cpu 25.033 total
```
So 5x slow down.
Could the GC heap growth algorithm be tuned? Other language runtimes, that are slower than Haskell's on this benchmark when our GC hint is in play, don't seem to suffer as badly without the hint:
> http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all
See e.g. Erlang. So: is there a better growth algorithm?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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's GC default heap growth strategy is not as good as other runtimes","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["GC","performance,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a GC performance ticket. The benchmark is the binary-trees benchmark, and the issue is whether or not GHC's ability to grow the heap without a heap check is comparably worse than other similar language runtimes. \r\n\r\nLooking at the binary-trees benchmark, we see that GHC does very well on a parallel system, when we give a GC hint to the size.\r\n\r\nE.g. the attached binary-trees program is very very competitive:\r\n\r\nCompile with:\r\n\r\n{{{\r\n ghc -O2 -fasm --make -threaded A.hs \r\n}}}\r\n\r\nRun with:\r\n\r\n{{{\r\n $ /A 20 +RTS -N4 -H340M\r\n}}}\r\n\r\nAnd we get:\r\n\r\n{{{\r\n $ time ./A +RTS -N4 -H340M -RTS 20 \r\nstretch tree of depth 21\t check: -1\r\n2097152\t trees of depth 4\t check: -2097152\r\n524288\t trees of depth 6\t check: -524288\r\n131072\t trees of depth 8\t check: -131072\r\n32768\t trees of depth 10\t check: -32768\r\n8192\t trees of depth 12\t check: -8192\r\n2048\t trees of depth 14\t check: -2048\r\n512\t trees of depth 16\t check: -512\r\n128\t trees of depth 18\t check: -128\r\n32\t trees of depth 20\t check: -32\r\nlong lived tree of depth 20\t check: -1\r\n./A +RTS -N4 -H340M -RTS 20 17.08s user 0.30s system 315% cpu 5.511 total\r\n}}}\r\n\r\nHowever, without that GC hint performance deteriorates dramatically,\r\n\r\n{{{\r\n$ time ./A +RTS -N4 -RTS 20 \r\nstretch tree of depth 21\t check: -1\r\n2097152\t trees of depth 4\t check: -2097152\r\n524288\t trees of depth 6\t check: -524288\r\n131072\t trees of depth 8\t check: -131072\r\n32768\t trees of depth 10\t check: -32768\r\n8192\t trees of depth 12\t check: -8192\r\n2048\t trees of depth 14\t check: -2048\r\n512\t trees of depth 16\t check: -512\r\n128\t trees of depth 18\t check: -128\r\n32\t trees of depth 20\t check: -32\r\nlong lived tree of depth 20\t check: -1\r\n./A +RTS -N4 -RTS 20 33.83s user 0.42s system 136% cpu 25.033 total\r\n}}}\r\n\r\nSo 5x slow down. \r\n\r\nCould the GC heap growth algorithm be tuned? Other language runtimes, that are slower than Haskell's on this benchmark when our GC hint is in play, don't seem to suffer as badly without the hint:\r\n\r\n http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all\r\n\r\nSee e.g. Erlang. So: is there a better growth algorithm?\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3062Adding a ":clear" clear-screen command to GHCi2019-07-07T19:05:35ZPorgesAdding a ":clear" clear-screen command to GHCiI have written a (hopeful) patch for this. I say hopeful because I'm not sure if it even compiles (I don't have the space to compile GHC at the moment...).
Anyway if this could be confirmed to work and then incorporated that would be ni...I have written a (hopeful) patch for this. I say hopeful because I'm not sure if it even compiles (I don't have the space to compile GHC at the moment...).
Anyway if this could be confirmed to work and then incorporated that would be nice :)
```
@@ -119,6 +119,7 @@
("browse!", keepGoing (browseCmd True), Nothing, completeModule),
("cd", keepGoing changeDirectory, Just filenameWordBreakChars, completeFilename),
("check", keepGoing checkModule, Nothing, completeHomeModule),
+ ("clear", keepGoing clearScreen, Nothing, completeNone),
("continue", keepGoing continueCmd, Nothing, completeNone),
("cmd", keepGoing cmdCmd, Nothing, completeIdentifier),
("ctags", keepGoing createCTagsFileCmd, Just filenameWordBreakChars, completeFilename),
@@ -200,6 +201,7 @@
" :browse[!] [[*]<mod>] display the names defined by module <mod>\n" ++
" (!: more details; *: all top-level names)\n" ++
" :cd <dir> change directory to <dir>\n" ++
+ " :clear clear the screen\n" ++
" :cmd <expr> run the commands returned by <expr>::IO String\n" ++
" :ctags [<file>] create tags file for Vi (default: \"tags\")\n" ++
" :def <cmd> <expr> define a command :<cmd>\n" ++
@@ -936,6 +938,15 @@
prev_context <- GHC.getContext
ok <- trySuccess $ GHC.load LoadAllTargets
afterLoad ok False prev_context
+
+clearScreen :: String -> GHCi ()
+clearScreen _ = do
+ let cmd = case os of
+ "windows" -> Just "cls"
+ "linux" -> Just "clear"
+ _ -> Nothing
+ didnt_work <- maybe (return True) shellEscape cmd
+ when didnt_work (io (putStrLn ("Error: unsupported operating system for command 'clear'. Please report a bug.")))
changeDirectory :: String -> GHCi ()
changeDirectory "" = do
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Adding a \":clear\" clear-screen command to GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I have written a (hopeful) patch for this. I say hopeful because I'm not sure if it even compiles (I don't have the space to compile GHC at the moment...).\r\n\r\nAnyway if this could be confirmed to work and then incorporated that would be nice :)\r\n\r\n{{{\r\n@@ -119,6 +119,7 @@\r\n (\"browse!\", keepGoing (browseCmd True),\tNothing, completeModule),\r\n (\"cd\", \tkeepGoing changeDirectory,\tJust filenameWordBreakChars, completeFilename),\r\n (\"check\",\tkeepGoing checkModule,\t\tNothing, completeHomeModule),\r\n+ (\"clear\", keepGoing clearScreen, Nothing, completeNone),\r\n (\"continue\", keepGoing continueCmd, Nothing, completeNone),\r\n (\"cmd\", keepGoing cmdCmd, Nothing, completeIdentifier),\r\n (\"ctags\",\tkeepGoing createCTagsFileCmd, \tJust filenameWordBreakChars, completeFilename),\r\n@@ -200,6 +201,7 @@\r\n \" :browse[!] [[*]<mod>] display the names defined by module <mod>\\n\" ++\r\n \" (!: more details; *: all top-level names)\\n\" ++\r\n \" :cd <dir> change directory to <dir>\\n\" ++\r\n+ \" :clear clear the screen\\n\" ++\r\n \" :cmd <expr> run the commands returned by <expr>::IO String\\n\" ++\r\n \" :ctags [<file>] create tags file for Vi (default: \\\"tags\\\")\\n\" ++\r\n \" :def <cmd> <expr> define a command :<cmd>\\n\" ++\r\n@@ -936,6 +938,15 @@\r\n prev_context <- GHC.getContext\r\n ok <- trySuccess $ GHC.load LoadAllTargets\r\n afterLoad ok False prev_context\r\n+ \r\n+clearScreen :: String -> GHCi ()\r\n+clearScreen _ = do\r\n+ let cmd = case os of\t\t\t\r\n+ \"windows\" -> Just \"cls\"\r\n+ \"linux\" -> Just \"clear\"\r\n+ _ -> Nothing\r\n+ didnt_work <- maybe (return True) shellEscape cmd\r\n+ when didnt_work (io (putStrLn (\"Error: unsupported operating system for command 'clear'. Please report a bug.\")))\r\n \r\n changeDirectory :: String -> GHCi ()\r\n changeDirectory \"\" = do\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3063Only at separate compilation: Conflicting family instance declarations2019-07-07T19:05:35ZdorinhoOnly at separate compilation: Conflicting family instance declarationsTake the following class:
class C a where
> type B a
Then the following instances only throw «Conflicting family instance declarations»,
if compiled separately:
instance C a where
> type B a = X a
instance C (Int,a) where
> typ...Take the following class:
class C a where
> type B a
Then the following instances only throw «Conflicting family instance declarations»,
if compiled separately:
instance C a where
> type B a = X a
instance C (Int,a) where
> type B (Int,a) = X a
Cheers,
> Dorinho
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Only at separate compilation: Conflicting family instance declarations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Take the following class:\r\n\r\nclass C a where \r\n type B a\r\n\r\nThen the following instances only throw «Conflicting family instance declarations», \r\nif compiled separately:\r\n\r\ninstance C a where\r\n type B a = X a\r\n\r\ninstance C (Int,a) where\r\n type B (Int,a) = X a\r\n\r\nCheers,\r\n Dorinho","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3064Very long compile times with type functions2019-07-07T19:05:34ZSimon Peyton JonesVery long compile times with type functionsthe attached module is a much reduced version of some type-level assurance
stuff (inspired by the Lightweight Monadic Regions paper) I am trying to
do. I am almost certain that it could be reduced further but it is late and
I want to get...the attached module is a much reduced version of some type-level assurance
stuff (inspired by the Lightweight Monadic Regions paper) I am trying to
do. I am almost certain that it could be reduced further but it is late and
I want to get this off my desk.
Note the 4 test functions, test11 .. test14. The following are timings for
compiling the module only with all test functions commented out, except
respectively, test11, test12, test13, and test14:
```
ben@sarun[1] > time ghc -c Bug2.hs
ghc -c Bug2.hs 1,79s user 0,04s system 99% cpu 1,836 total
ben@sarun[1] > time ghc -c Bug2.hs
ghc -c Bug2.hs 5,87s user 0,14s system 99% cpu 6,028 total
ben@sarun[1] > time ghc -c Bug2.hs
ghc -c Bug2.hs 23,52s user 0,36s system 99% cpu 23,899 total
ben@sarun[1] > time ghc -c Bug2.hs
ghc -c Bug2.hs 102,20s user 1,32s system 97% cpu 1:45,89 total
```
It seems something is scaling very badly. You really don't want to wait for
a version with 20 levels of nesting to compile...
If anyone has a good explanation for this, I'd be grateful.
BTW, I am not at all certain that this is ghc's fault, it may well be my
program, i.e. the constraints are too complex, whatever. I have no idea how
hard it is for the compiler to do all the unification. Also, the problem is
not of much practical relevance, as no sensible program will use more than
a handful levels of nesting.
SLPJ says: let's investigate this once the new solver is done.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ben.franksen@online.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Very long compile times with type functions","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chak"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ben.franksen@online.de"],"type":"Bug","description":"the attached module is a much reduced version of some type-level assurance\r\nstuff (inspired by the Lightweight Monadic Regions paper) I am trying to\r\ndo. I am almost certain that it could be reduced further but it is late and\r\nI want to get this off my desk.\r\n\r\nNote the 4 test functions, test11 .. test14. The following are timings for\r\ncompiling the module only with all test functions commented out, except\r\nrespectively, test11, test12, test13, and test14:\r\n{{{\r\nben@sarun[1] > time ghc -c Bug2.hs\r\nghc -c Bug2.hs 1,79s user 0,04s system 99% cpu 1,836 total\r\n\r\nben@sarun[1] > time ghc -c Bug2.hs\r\nghc -c Bug2.hs 5,87s user 0,14s system 99% cpu 6,028 total\r\n\r\nben@sarun[1] > time ghc -c Bug2.hs\r\nghc -c Bug2.hs 23,52s user 0,36s system 99% cpu 23,899 total\r\n\r\nben@sarun[1] > time ghc -c Bug2.hs\r\nghc -c Bug2.hs 102,20s user 1,32s system 97% cpu 1:45,89 total\r\n}}}\r\nIt seems something is scaling very badly. You really don't want to wait for\r\na version with 20 levels of nesting to compile...\r\n\r\nIf anyone has a good explanation for this, I'd be grateful.\r\n\r\nBTW, I am not at all certain that this is ghc's fault, it may well be my\r\nprogram, i.e. the constraints are too complex, whatever. I have no idea how\r\nhard it is for the compiler to do all the unification. Also, the problem is\r\nnot of much practical relevance, as no sensible program will use more than\r\na handful levels of nesting.\r\n\r\nSLPJ says: let's investigate this once the new solver is done.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3065Reorder tests in quot to improve code2019-07-07T19:05:34ZSimon Peyton JonesReorder tests in quot to improve code\[SLPJ: capturing an email thread in a ticket\]
Krasimir Angelov found that this function:
```
a `quot` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise ...\[SLPJ: capturing an email thread in a ticket\]
Krasimir Angelov found that this function:
```
a `quot` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise = a `quotInt` b
```
is expanded to:
```
a `quot` b =
if b == 0
then divZeroError
else if a == minBound
then if b == (-1)
then overflowError
else a `quotInt` b
else a `quotInt` b
```
Then the compiler sees that b is a constant and computes that b == 0
is False and b == (-1) is also False so it could eliminate two If
statements. The result is:
```
a `quot` b =
if a == minBound
then a `quotInt` b
else a `quotInt` b
```
and this is exactly what we get. I bet that if the original function was:
```
a `quot` b
| b == 0 = divZeroError
| b == (-1) && a == minBound = overflowError -- Note the changed order here
| otherwise = a `quotInt` b
```
then we would get what we want. I think that it is much more often to
have division where the divisor is known so we will get the best code
in this case.
Shortly afterwards, Bertram Felgenhauer tried it out. It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers.
For a patch, see
> http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch
(SLPJ: I've attached it to the ticket too)
Nofib results extract:
```
------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed
------------------------------------------------------------------------
fish -0.7% -5.3% 0.05 0.04
primes -0.0% +28.5% +25.6% +25.5%
wheel-sieve2 -0.0% -0.3% -17.9% -18.6%
------------------------------------------------------------------------
Min -0.9% -5.3% -17.9% -18.6%
Max +0.1% +28.5% +25.6% +25.5%
Geometric Mean -0.2% +0.2% -0.0% +0.2%
```
'primes' is an outlier - the other slowdowns are below 3%
What happens in 'primes' is that 'mod' no longer gets inlined;
apparently it now looks bigger to the compiler than before.
Using -funfolding-use-threshold=10 brings the benchmark back to its
original speed, despite the extra comparison before doing the
division.
In 'wheel-sieve2', the first different optimization choice I see is
again a 'mod' that is no longer inlined; this leads to a change in other
inlining choices that result in a speedup for reasons that I have not
investigated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------------------------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bertram.felgenhauer@googlemail.com; kr.angelov@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reorder tests in quot to improve code","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bertram.felgenhauer@googlemail.com; kr.angelov@gmail.com"],"type":"Bug","description":"[SLPJ: capturing an email thread in a ticket]\r\n\r\nKrasimir Angelov found that this function:\r\n{{{\r\na `quot` b\r\n | b == 0 = divZeroError\r\n | a == minBound && b == (-1) = overflowError\r\n | otherwise = a `quotInt` b\r\n}}}\r\nis expanded to:\r\n{{{\r\na `quot` b =\r\n if b == 0\r\n then divZeroError\r\n else if a == minBound\r\n then if b == (-1)\r\n then overflowError\r\n else a `quotInt` b\r\n else a `quotInt` b\r\n}}}\r\nThen the compiler sees that b is a constant and computes that b == 0\r\nis False and b == (-1) is also False so it could eliminate two If\r\nstatements. The result is:\r\n{{{\r\na `quot` b =\r\n if a == minBound\r\n then a `quotInt` b\r\n else a `quotInt` b\r\n}}}\r\nand this is exactly what we get. I bet that if the original function was:\r\n{{{\r\na `quot` b\r\n | b == 0 = divZeroError\r\n | b == (-1) && a == minBound = overflowError -- Note the changed order here\r\n | otherwise = a `quotInt` b\r\n}}}\r\nthen we would get what we want. I think that it is much more often to\r\nhave division where the divisor is known so we will get the best code\r\nin this case.\r\n\r\nShortly afterwards, Bertram Felgenhauer tried it out. It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers.\r\n\r\nFor a patch, see\r\n http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch\r\n(SLPJ: I've attached it to the ticket too)\r\n\r\nNofib results extract:\r\n{{{\r\n------------------------------------------------------------------------\r\n Program Size Allocs Runtime Elapsed\r\n------------------------------------------------------------------------\r\n fish -0.7% -5.3% 0.05 0.04\r\n primes -0.0% +28.5% +25.6% +25.5%\r\n wheel-sieve2 -0.0% -0.3% -17.9% -18.6%\r\n------------------------------------------------------------------------\r\n Min -0.9% -5.3% -17.9% -18.6%\r\n Max +0.1% +28.5% +25.6% +25.5%\r\n Geometric Mean -0.2% +0.2% -0.0% +0.2%\r\n}}}\r\n'primes' is an outlier - the other slowdowns are below 3%\r\n\r\nWhat happens in 'primes' is that 'mod' no longer gets inlined;\r\napparently it now looks bigger to the compiler than before.\r\n\r\nUsing -funfolding-use-threshold=10 brings the benchmark back to its\r\noriginal speed, despite the extra comparison before doing the\r\ndivision.\r\n\r\nIn 'wheel-sieve2', the first different optimization choice I see is\r\nagain a 'mod' that is no longer inlined; this leads to a change in other\r\ninlining choices that result in a speedup for reasons that I have not\r\ninvestigated.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/3066Crash with bogus FFI declaration2019-07-07T19:05:33ZSimon Peyton JonesCrash with bogus FFI declarationBen Franksen finds this:
```
{-# LANGUAGE ForeignFunctionInterface, RankNTypes #-}
import Foreign
type X u = Ptr ()
foreign import ccall bla :: (forall u. X u) -> IO ()
```
I know of course that I must not use fancy types in foreign im...Ben Franksen finds this:
```
{-# LANGUAGE ForeignFunctionInterface, RankNTypes #-}
import Foreign
type X u = Ptr ()
foreign import ccall bla :: (forall u. X u) -> IO ()
```
I know of course that I must not use fancy types in foreign imports. I
forgot for a moment and instead of an error message got:
```
ben@sarun> ghci Bug3
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( Bug3.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
unboxArg:
Bug3.hs:4:0-51 forall u{tv aht} [tv].
main:Main.X{tc rhp} u{tv aht} [tv]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Crash with bogus FFI declaration","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Ben Franksen finds this:\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface, RankNTypes #-}\r\nimport Foreign\r\ntype X u = Ptr ()\r\nforeign import ccall bla :: (forall u. X u) -> IO ()\r\n}}}\r\nI know of course that I must not use fancy types in foreign imports. I\r\nforgot for a moment and instead of an error message got:\r\n{{{\r\nben@sarun> ghci Bug3\r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( Bug3.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n unboxArg:\r\n Bug3.hs:4:0-51 forall u{tv aht} [tv].\r\n main:Main.X{tc rhp} u{tv aht} [tv]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3067GHCi panics with 'initTc:LIE' while :stepping on code with funny types2019-07-07T19:05:32ZmnislaihGHCi panics with 'initTc:LIE' while :stepping on code with funny typesThis is due to runtime type reconstruction not dealing correctly with type functions.
I managed to come up a minimal example.
```
{-# LANGUAGE TypeFamilies #-}
type family Id x
type instance Id Int = Int
type instance Id Bool = Bool
...This is due to runtime type reconstruction not dealing correctly with type functions.
I managed to come up a minimal example.
```
{-# LANGUAGE TypeFamilies #-}
type family Id x
type instance Id Int = Int
type instance Id Bool = Bool
class Convert x y where convert :: x -> y
instance Convert x x where convert = id
f :: Convert a (Id a) => a -> Id a
f x = convert x
g :: Convert a (Id a) => a -> Id a
g x = let x' = f x in x'
}
{{{
[1 of 1] Compiling Main ( ../code/debuggerExamples/lie.hs, interpreted )
Ok, modules loaded: Main.
*Main GOA> :step g False
:step g False
Stopped at ../code/debuggerExamples/lie.hs:15:0-23
_result :: Id a = _
14 g :: Convert a (Id a) => a -> Id a
15 g x = let x' = f x in x'
^^^^^^^^^^^^^^^^^^^^^^^^
[../code/debuggerExamples/lie.hs:15:0-23] *Main GOA> :step
:step
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
initTc:LIE
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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 panics with 'initTc:LIE' while :stepping on code with funny types","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is due to runtime type reconstruction not dealing correctly with type functions.\r\n\r\nI managed to come up a minimal example.\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family Id x\r\ntype instance Id Int = Int\r\ntype instance Id Bool = Bool\r\n\r\nclass Convert x y where convert :: x -> y\r\ninstance Convert x x where convert = id\r\n\r\nf :: Convert a (Id a) => a -> Id a\r\nf x = convert x\r\n\r\ng :: Convert a (Id a) => a -> Id a\r\ng x = let x' = f x in x'\r\n}\r\n{{{\r\n[1 of 1] Compiling Main ( ../code/debuggerExamples/lie.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main GOA> :step g False\r\n:step g False\r\nStopped at ../code/debuggerExamples/lie.hs:15:0-23\r\n_result :: Id a = _\r\n14 g :: Convert a (Id a) => a -> Id a\r\n15 g x = let x' = f x in x'\r\n ^^^^^^^^^^^^^^^^^^^^^^^^\r\n[../code/debuggerExamples/lie.hs:15:0-23] *Main GOA> :step\r\n:step\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tinitTc:LIE\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3068broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/specia...2019-07-07T19:05:32Znr@eecs.harvard.edubroken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.htmlThe GHC documentatation at http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html contains a broken link to the documentation for the GHC.Prim module.
The link is to http://www.haskell.org/ghc/docs/latest/html/librarie...The GHC documentatation at http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html contains a broken link to the documentation for the GHC.Prim module.
The link is to http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Prim.html, which is a dangling reference.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC documentatation at http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html contains a broken link to the documentation for the GHC.Prim module.\r\n\r\nThe link is to http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Prim.html, which is a dangling reference.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3069misspelled word in description of syntax extensions: s/enerated/enumerated/2019-07-07T19:05:32Znr@eecs.harvard.edumisspelled word in description of syntax extensions: s/enerated/enumerated/In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html there is a misspelling.
s/enerated/enumerated/
as in `the enumerated sequence [Monday..]`
A quick wander about the Wiki didn't lead me to the place where the...In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html there is a misspelling.
s/enerated/enumerated/
as in `the enumerated sequence [Monday..]`
A quick wander about the Wiki didn't lead me to the place where the master source for GHC doco is stored. If someone can tell me I can fix this sort of thing myself. (And in fact if someone wants to email me now, I can retire this ticket myself.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"misspelled word in description of syntax extensions: s/enerated/enumerated/","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html there is a misspelling.\r\n\r\ns/enerated/enumerated/\r\n\r\nas in {{{the enumerated sequence [Monday..]}}}\r\n\r\nA quick wander about the Wiki didn't lead me to the place where the master source for GHC doco is stored. If someone can tell me I can fix this sort of thing myself. (And in fact if someone wants to email me now, I can retire this ticket myself.)","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3070floor(0/0) should not be defined2019-07-07T19:05:31Zcarettefloor(0/0) should not be definedfloor(0/0) returns some giant negative integer - it should return NaN or undefined.
The bug appears to be in some implementation of 'properFraction' in the standard library.
\[from Andrej Bauer, from Barak Pearlmutter (from ???)\]
<de...floor(0/0) returns some giant negative integer - it should return NaN or undefined.
The bug appears to be in some implementation of 'properFraction' in the standard library.
\[from Andrej Bauer, from Barak Pearlmutter (from ???)\]
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"floor(0/0) should not be defined","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"floor(0/0) returns some giant negative integer - it should return NaN or undefined.\r\n\r\nThe bug appears to be in some implementation of 'properFraction' in the standard library.\r\n\r\n[from Andrej Bauer, from Barak Pearlmutter (from ???)]","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1squadettesquadettehttps://gitlab.haskell.org/ghc/ghc/-/issues/3071Network.Socket.recv throws IOException on reading 0 bytes2019-07-07T19:05:31ZtibbeNetwork.Socket.recv throws IOException on reading 0 bytesMy man pages has the following to say about the return value of `recv`:
> These calls return the number of bytes received, or -1 if an error
> occurred.
> For TCP sockets, the return value 0 means the peer has closed its half
> side of...My man pages has the following to say about the return value of `recv`:
> These calls return the number of bytes received, or -1 if an error
> occurred.
> For TCP sockets, the return value 0 means the peer has closed its half
> side of the connection.
This means that it's absolutely fine to read 0 bytes when using e.g. UDP socket.
However, the `Network.Socket.recv` function always throws an exception upon reading 0 bytes regardless of the protocol family.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Network.Socket.recv throws IOException on reading 0 bytes","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My man pages has the following to say about the return value of `recv`:\r\n\r\n These calls return the number of bytes received, or -1 if an error\r\n occurred.\r\n\r\n For TCP sockets, the return value 0 means the peer has closed its half\r\n side of the connection.\r\n\r\nThis means that it's absolutely fine to read 0 bytes when using e.g. UDP socket.\r\n\r\nHowever, the `Network.Socket.recv` function always throws an exception upon reading 0 bytes regardless of the protocol family.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3072considerations for management of shared libs2019-07-07T19:05:31Zduncanconsiderations for management of shared libsSome thought needs to be put into how to manage shared libs on the various platforms we support. Sadly the solution is likely to be different on Windows vs OSX vs ELF-format platforms. For ELF platforms our current idea is to put all sha...Some thought needs to be put into how to manage shared libs on the various platforms we support. Sadly the solution is likely to be different on Windows vs OSX vs ELF-format platforms. For ELF platforms our current idea is to put all shared libs in `/usr{/local}/lib` with names like `libHSfoo-x.y.z-ghc-a.b.c.so`. Having them all in the system dir like that has it's downsides and it does not work for per-user installs. If we want to have multiple instances of the same version of a lib then it's even more problematic.
All ELF linkers support the RPATH/RUNPATH mechanism for executables and shared libs to locate each other without them having to be on the standard linker path. This basically involves embedding the path in them at link time. It must be acknowledged that some linux distributions eschew the use of rpath for various reasons. We must take that into consideration. Also we must consider relocatable/redistributable binaries...
The GNU and Solaris linkers support an extension which allows the above mechanism to work, even for relocatable binaries (so long as the libs are kept relative to the executable). Basically one can set an rpath that uses `$ORIGIN` and at runtime the `$ORIGIN` is substituted for the file system location of the executable or shared lib in question.
Note that on Linux at least the `$ORIGIN` is always passed by the kernel so that the dynamic linker can resolve it. See the attached program which demonstrates this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"considerations for management of shared libs","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Some thought needs to be put into how to manage shared libs on the various platforms we support. Sadly the solution is likely to be different on Windows vs OSX vs ELF-format platforms. For ELF platforms our current idea is to put all shared libs in `/usr{/local}/lib` with names like `libHSfoo-x.y.z-ghc-a.b.c.so`. Having them all in the system dir like that has it's downsides and it does not work for per-user installs. If we want to have multiple instances of the same version of a lib then it's even more problematic.\r\n\r\nAll ELF linkers support the RPATH/RUNPATH mechanism for executables and shared libs to locate each other without them having to be on the standard linker path. This basically involves embedding the path in them at link time. It must be acknowledged that some linux distributions eschew the use of rpath for various reasons. We must take that into consideration. Also we must consider relocatable/redistributable binaries...\r\n\r\nThe GNU and Solaris linkers support an extension which allows the above mechanism to work, even for relocatable binaries (so long as the libs are kept relative to the executable). Basically one can set an rpath that uses `$ORIGIN` and at runtime the `$ORIGIN` is substituted for the file system location of the executable or shared lib in question.\r\n\r\nNote that on Linux at least the `$ORIGIN` is always passed by the kernel so that the dynamic linker can resolve it. See the attached program which demonstrates this.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3073Avoid reconstructing dictionaries in recursive instance methods2019-07-07T19:05:31ZSimon Peyton JonesAvoid reconstructing dictionaries in recursive instance methodsGanesh writes: I have a problem in GHC 6.10 with functions in a class instance calling
other functions in the same class instance. It seems that the dictionary
is freshly constructed for this call, despite being already available.
The r...Ganesh writes: I have a problem in GHC 6.10 with functions in a class instance calling
other functions in the same class instance. It seems that the dictionary
is freshly constructed for this call, despite being already available.
The reason I care is that I want to memoise some expensive computations
inside the dictionary for each instance. \[Obviously I also have to make
sure that the dictionary isn't constructed multiple times by external
callers, but I can make other arrangements to ensure that.\]
To see the problem in action, run main from the attached code. In GHC 6.8
and before, this only executes the trace statement once. In GHC 6.10, the
trace statement executes twice, at all optimisation levels.
This seems related to #2902, but I'm a little unclear on whether it's the same problem or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh@earth.li |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Avoid reconstructing dictionaries in recursive instance methods","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ganesh@earth.li"],"type":"Bug","description":"Ganesh writes: I have a problem in GHC 6.10 with functions in a class instance calling\r\nother functions in the same class instance. It seems that the dictionary\r\nis freshly constructed for this call, despite being already available.\r\n\r\nThe reason I care is that I want to memoise some expensive computations\r\ninside the dictionary for each instance. [Obviously I also have to make\r\nsure that the dictionary isn't constructed multiple times by external\r\ncallers, but I can make other arrangements to ensure that.]\r\n\r\nTo see the problem in action, run main from the attached code. In GHC 6.8\r\nand before, this only executes the trace statement once. In GHC 6.10, the\r\ntrace statement executes twice, at all optimisation levels.\r\n\r\nThis seems related to #2902, but I'm a little unclear on whether it's the same problem or not.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3074Template Haskell does not support type families.2019-07-07T19:05:30ZSerguey ZefirovTemplate Haskell does not support type families.```
{-# LANGUAGE TemplateHaskell, TypeFamilies #-}
import Language.Haskell.TH
type family A a
$((\x -> x >>= (runIO . (print . ppr)) >> return []) $
[d|type instance A (Maybe Int) = Int|])
```
GHCi load result:
```
[1 of 1] Compil...```
{-# LANGUAGE TemplateHaskell, TypeFamilies #-}
import Language.Haskell.TH
type family A a
$((\x -> x >>= (runIO . (print . ppr)) >> return []) $
[d|type instance A (Maybe Int) = Int|])
```
GHCi load result:
```
[1 of 1] Compiling Main ( a.hs, interpreted )
type A = GHC.Types.Int
Ok, modules loaded: Main.
```
TySynD has list of Names as an argument list whereas type families header should have a list of Types.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell does not support type families.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["families","haskell,","template","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TemplateHaskell, TypeFamilies #-}\r\n\r\nimport Language.Haskell.TH\r\n\r\ntype family A a\r\n\r\n\r\n$((\\x -> x >>= (runIO . (print . ppr)) >> return []) $\r\n [d|type instance A (Maybe Int) = Int|])\r\n}}}\r\n\r\nGHCi load result:\r\n{{{\r\n[1 of 1] Compiling Main ( a.hs, interpreted )\r\ntype A = GHC.Types.Int\r\nOk, modules loaded: Main.\r\n}}}\r\n\r\nTySynD has list of Names as an argument list whereas type families header should have a list of Types.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3075validation requires a tool that is not included in utils2019-07-07T19:05:30Znr@eecs.harvard.eduvalidation requires a tool that is not included in utilsAt present it is not possible to validate without HsColour, but HsColour is not included in utils. To make matters worse, HsColour is not available through Debian, and even cabal, which could be used to install HsColour, is not available...At present it is not possible to validate without HsColour, but HsColour is not included in utils. To make matters worse, HsColour is not available through Debian, and even cabal, which could be used to install HsColour, is not available through Debian. To require me to install Cabal to install HsColour to validate changes made to GHC's back end is at least one too many levels of indirection. (I routinely build GHC on three different computers, and a fourth is not unheard of, so if the installation isn't easily supported by my existing Linux distros, I want no part of it.)
I'd like the validate/build process changed to reach one of two outcomes:
1. It becomes permissible to validate without HsColour, and this happens by default and automatically on systems where HsColour is not present.
1. HsColour is included in utils, and the validate script automatically finds it there and builds it at need.
P.S. I am quite grateful for the earlier work that enables me to build the compiler without HsColour. But I also want to be able to contribute changes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"validation requires a tool that is not included in utils","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At present it is not possible to validate without HsColour, but HsColour is not included in utils. To make matters worse, HsColour is not available through Debian, and even cabal, which could be used to install HsColour, is not available through Debian. To require me to install Cabal to install HsColour to validate changes made to GHC's back end is at least one too many levels of indirection. (I routinely build GHC on three different computers, and a fourth is not unheard of, so if the installation isn't easily supported by my existing Linux distros, I want no part of it.)\r\n\r\nI'd like the validate/build process changed to reach one of two outcomes:\r\n\r\n 1. It becomes permissible to validate without HsColour, and this happens by default and automatically on systems where HsColour is not present.\r\n 1. HsColour is included in utils, and the validate script automatically finds it there and builds it at need.\r\n\r\nP.S. I am quite grateful for the earlier work that enables me to build the compiler without HsColour. But I also want to be able to contribute changes.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3076Make genericLength tail-recursive so it doesn't overflow stack2021-11-02T09:27:33ZSyzygiesMake genericLength tail-recursive so it doesn't overflow stackA likely use for genericLength is to count lists of more than Int elements. However, the source code is not tail-recursive, making a poor "consumer", so genericLength easily overflows stack.
Here is the source code from 6.10.1:
```
gen...A likely use for genericLength is to count lists of more than Int elements. However, the source code is not tail-recursive, making a poor "consumer", so genericLength easily overflows stack.
Here is the source code from 6.10.1:
```
genericLength :: (Num i) => [b] -> i
genericLength [] = 0
genericLength (_:l) = 1 + genericLength l
```
Here is a proposed alternative:
```
genericLength ∷ (Num i) ⇒ [b] → i
genericLength = len 0 where
len n [] = n
len n (_:xt) = len (n+1) xt
```
In my test application (enumerating the 66,960,965,307 atomic lattices on six atoms) this alternative avoids overflowing the stack.
\[This is not the same issue as http://hackage.haskell.org/trac/ghc/ticket/2962\]
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make genericLength tail-recursive so it doesn't overflow stack","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A likely use for genericLength is to count lists of more than Int elements. However, the source code is not tail-recursive, making a poor \"consumer\", so genericLength easily overflows stack.\r\n\r\nHere is the source code from 6.10.1:\r\n\r\n{{{\r\ngenericLength :: (Num i) => [b] -> i\r\ngenericLength [] = 0\r\ngenericLength (_:l) = 1 + genericLength l\r\n}}}\r\n\r\nHere is a proposed alternative:\r\n\r\n{{{\r\ngenericLength ∷ (Num i) ⇒ [b] → i\r\ngenericLength = len 0 where\r\n len n [] = n\r\n len n (_:xt) = len (n+1) xt\r\n}}}\r\n\r\nIn my test application (enumerating the 66,960,965,307 atomic lattices on six atoms) this alternative avoids overflowing the stack.\r\n\r\n[This is not the same issue as http://hackage.haskell.org/trac/ghc/ticket/2962]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3077'make' fails in utils (6.11)2019-07-07T19:05:30Znr@eecs.harvard.edu'make' fails in utils (6.11)In order to get 'make boot' to work in compiler, I tried running 'make' in utils.
Something's off with configuration it appears. I'm attaching full output.
Sorry to keep submitting these things with no patches. I don't have a strong eno...In order to get 'make boot' to work in compiler, I tried running 'make' in utils.
Something's off with configuration it appears. I'm attaching full output.
Sorry to keep submitting these things with no patches. I don't have a strong enough picture of what's *supposed* to happen during build to be confident of making things better not worse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"'make' fails in utils (6.11)","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In order to get 'make boot' to work in compiler, I tried running 'make' in utils.\r\nSomething's off with configuration it appears. I'm attaching full output.\r\n\r\nSorry to keep submitting these things with no patches. I don't have a strong enough picture of what's ''supposed'' to happen during build to be confident of making things better not worse.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3078Erroneous warnings for -XPatternGuards2019-09-30T21:35:27ZguestErroneous warnings for -XPatternGuardsAs nonstandard PatternGuards I get a meaningless warning:
```
walltest.hs:8:10:
Warning: Pattern match(es) are non-exhaustive
In the definition of `n': Patterns not matched:
Ok, modules loaded: Main.
```
```
{-# LANGUA...As nonstandard PatternGuards I get a meaningless warning:
```
walltest.hs:8:10:
Warning: Pattern match(es) are non-exhaustive
In the definition of `n': Patterns not matched:
Ok, modules loaded: Main.
```
```
{-# LANGUAGE PatternGuards #-}
{-# OPTIONS -Wall #-}
data T = A Int | B Int
funny :: T -> Int
funny t = n
where n | A x <- t = x
| B x <- t = x
```
But none of that happens when using a case expression for the same thing:
```
{-# OPTIONS -Wall #-}
data T = A Int | B Int
funny :: T -> Int
funny t = n
where n = case t of
(A x) -> x
(B x) -> x
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Erroneous warnings for -XPatternGuards","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As nonstandard PatternGuards I get a meaningless warning:\r\n{{{\r\nwalltest.hs:8:10:\r\n Warning: Pattern match(es) are non-exhaustive\r\n In the definition of `n': Patterns not matched:\r\nOk, modules loaded: Main.\r\n}}}\r\n\r\n\r\n{{{\r\n{-# LANGUAGE PatternGuards #-}\r\n{-# OPTIONS -Wall #-}\r\n\r\ndata T = A Int | B Int\r\n\r\nfunny :: T -> Int\r\nfunny t = n\r\n where n | A x <- t = x\r\n | B x <- t = x\r\n}}}\r\n\r\nBut none of that happens when using a case expression for the same thing:\r\n{{{\r\n{-# OPTIONS -Wall #-}\r\n\r\ndata T = A Int | B Int\r\n\r\nfunny :: T -> Int\r\nfunny t = n\r\n where n = case t of\r\n (A x) -> x\r\n (B x) -> x\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3079LANGUAGE pragma fails if it falls on a 1024-byte boundary2019-07-07T19:05:29ZDeewiantLANGUAGE pragma fails if it falls on a 1024-byte boundaryPutting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 byt...Putting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 bytes or be wholly inside an aligned 1024-byte range?
```
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
{-# LANGUAGE ScopedTypeVariables #-}
main = return ()
```
Removing absolutely anything prior to the start of the LANGUAGE pragma will make it work: one of the exes, an entire line, any whitespace, whatever.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LANGUAGE pragma fails if preceded by too many comments","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Putting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 bytes or be wholly inside an aligned 1024-byte range?\r\n\r\n{{{\r\n-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\nmain = return ()\r\n}}}\r\n\r\nRemoving absolutely anything prior to the start of the LANGUAGE pragma will make it work: one of the exes, an entire line, any whitespace, whatever.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3080Show more instances with :info2019-07-07T19:05:29ZjosefShow more instances with :infoToday I was really stumped by the rule used to select which instances are shown with the :info command. I did the following:
```
newtype Control.Monad.Writer.Lazy.Writer w a
= Control.Monad.Writer.Lazy.Writer {Control.Monad.Writer.Laz...Today I was really stumped by the rule used to select which instances are shown with the :info command. I did the following:
```
newtype Control.Monad.Writer.Lazy.Writer w a
= Control.Monad.Writer.Lazy.Writer {Control.Monad.Writer.Lazy.runWriter :: (a,
w)}
-- Defined in Control.Monad.Writer.Lazy
instance Functor (Control.Monad.Writer.Lazy.Writer w)
-- Defined in Control.Monad.Writer.Lazy
```
I was really surprised not to see a Monad instance which, after all, is the raison d'entre of the Writer type. After some investigation I found out that this behavior is a combination of ghci's rule not to show instances which involves stuff not in scope and the fact that Monoid wasn't in scope.
Now, personally I tend to want to see everything when I use the :info command so my preference would be to see all instances. But I realize that you came up with the current rule for a reason and so here are some alternative ways how to please me.
The first one is to have some kind of flag to give to :info so that it shows all instances. One might of course make it so that a flag is needed to suppress extraneous instances and get the current behavior. That would actually be my personal preference.
Another way, which I'm not sure I like but would at least help in the example above, is to note that the type I'm asking about is not in scope in the first place. So I'm not interested in 'in scope stuff' at all and so showing me all instances, even those including things not in scope, isn't very likely to confuse me. This rule would have the rather confusing effect of potentially showing less information about stuff that is in scope compared to things that are not in scope. But despite this confusing consequence I find the rule very sensible, so I'm in two minds about it.
Anyway, having some way to see all instances would be nice.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show more instances with :info","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Today I was really stumped by the rule used to select which instances are shown with the :info command. I did the following:\r\n{{{\r\nnewtype Control.Monad.Writer.Lazy.Writer w a\r\n = Control.Monad.Writer.Lazy.Writer {Control.Monad.Writer.Lazy.runWriter :: (a,\r\n w)}\r\n \t-- Defined in Control.Monad.Writer.Lazy\r\ninstance Functor (Control.Monad.Writer.Lazy.Writer w)\r\n -- Defined in Control.Monad.Writer.Lazy\r\n}}}\r\nI was really surprised not to see a Monad instance which, after all, is the raison d'entre of the Writer type. After some investigation I found out that this behavior is a combination of ghci's rule not to show instances which involves stuff not in scope and the fact that Monoid wasn't in scope.\r\n\r\nNow, personally I tend to want to see everything when I use the :info command so my preference would be to see all instances. But I realize that you came up with the current rule for a reason and so here are some alternative ways how to please me. \r\n\r\nThe first one is to have some kind of flag to give to :info so that it shows all instances. One might of course make it so that a flag is needed to suppress extraneous instances and get the current behavior. That would actually be my personal preference.\r\n\r\nAnother way, which I'm not sure I like but would at least help in the example above, is to note that the type I'm asking about is not in scope in the first place. So I'm not interested in 'in scope stuff' at all and so showing me all instances, even those including things not in scope, isn't very likely to confuse me. This rule would have the rather confusing effect of potentially showing less information about stuff that is in scope compared to things that are not in scope. But despite this confusing consequence I find the rule very sensible, so I'm in two minds about it.\r\n\r\nAnyway, having some way to see all instances would be nice.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/3081Double output after Ctrl+C on Windows2020-07-27T06:47:34ZNeil MitchellDouble output after Ctrl+C on Windows```
C:\Temp>type Test.hs
import Control.Exception
import System.Cmd
main = system "sleep 1m" `finally` putStrLn "goodbye"
C:\Temp>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
C:\Temp>ghc --make Test.hs
...```
C:\Temp>type Test.hs
import Control.Exception
import System.Cmd
main = system "sleep 1m" `finally` putStrLn "goodbye"
C:\Temp>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
C:\Temp>ghc --make Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test.exe ...
C:\Temp>test.exe
^Cgoodbye
goodbye
C:\Temp>
```
The `^C` is the consoles way of saying that Ctrl+C was pressed - i.e. I ran the program and hit Ctrl+C while the sleep was still ongoing. I can replicate this issue from the DOS prompt and from the Cygwin prompt. It does not occur from GHCi.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Finally run twice on Ctrl+C","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nC:\\Temp>type Test.hs\r\nimport Control.Exception\r\nimport System.Cmd\r\nmain = system \"sleep 1m\" `finally` putStrLn \"goodbye\"\r\n\r\nC:\\Temp>ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.1\r\n\r\nC:\\Temp>ghc --make Test.hs\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\nLinking Test.exe ...\r\n\r\nC:\\Temp>test.exe\r\n^Cgoodbye\r\ngoodbye\r\nC:\\Temp>\r\n}}}\r\n\r\nThe {{{^C}}} is the consoles way of saying that Ctrl+C was pressed - i.e. I ran the program and hit Ctrl+C while the sleep was still ongoing. I can replicate this issue from the DOS prompt and from the Cygwin prompt. It does not occur from GHCi.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3082Unclear warning message: Attempting to re-export hidden constructors2019-07-07T19:05:29ZksfUnclear warning message: Attempting to re-export hidden constructorsJust stumbled upon this after changing a type def to a data def:
Foo.hs:
```
module Foo (Foo) where
data Foo = Bar | Baz
```
Bar.hs:
```
module Bar (Foo.Foo(..)) where
import Foo
```
```
Bar.hs:1:12:
Warning: The export item `...Just stumbled upon this after changing a type def to a data def:
Foo.hs:
```
module Foo (Foo) where
data Foo = Bar | Baz
```
Bar.hs:
```
module Bar (Foo.Foo(..)) where
import Foo
```
```
Bar.hs:1:12:
Warning: The export item `Foo(..)'
suggests that `Foo' has constructors or class methods,
but it has none
```
1. ..while it actually has constructors.
I think it should say "The export item 'Foo(..)' suggests that 'Foo' has visible constructors or class methods, but it has none", or something even more specific to the re-export case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unclear warning message: Attempting to re-export hidden constructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just stumbled upon this after changing a type def to a data def:\r\n\r\nFoo.hs:\r\n{{{\r\nmodule Foo (Foo) where\r\n\r\ndata Foo = Bar | Baz\r\n}}}\r\nBar.hs:\r\n{{{\r\nmodule Bar (Foo.Foo(..)) where\r\n\r\nimport Foo\r\n}}}\r\n{{{\r\nBar.hs:1:12:\r\n Warning: The export item `Foo(..)'\r\n suggests that `Foo' has constructors or class methods,\r\n but it has none\r\n}}}\r\n...while it actually has constructors.\r\n\r\nI think it should say \"The export item 'Foo(..)' suggests that 'Foo' has visible constructors or class methods, but it has none\", or something even more specific to the re-export case.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3083Win32 package should bind SHGetFolderPath2019-07-07T19:05:29ZduncanWin32 package should bind SHGetFolderPathCurrently Cabal binds this function so that we can find the "Program Files" directory on Windows:
```
foreign import stdcall unsafe "shlobj.h SHGetFolderPathA"
c_SHGetFolderPath :: Ptr () -> CInt -> Ptr () -> CInt -> CString -> IO CInt...Currently Cabal binds this function so that we can find the "Program Files" directory on Windows:
```
foreign import stdcall unsafe "shlobj.h SHGetFolderPathA"
c_SHGetFolderPath :: Ptr () -> CInt -> Ptr () -> CInt -> CString -> IO CInt
```
This is fine except that it does not work in ghci because we have no way to tell ghci that it would need to link to `shell32.dll`. As it happens we do not have to tell the static linker to use `shell32.dll` because it appears to link to it by default. This of course means that `runghc Setup` does not work on Windows for Cabal itself which trips up many users. The fact that the `README` tells people to use `ghc --make Setup` instead doesn't help a great deal. See [Cabal ticket \#325](http://hackage.haskell.org/trac/hackage/ticket/325)
What would be nice is if the Win32 package would bind [SHGetFolderPath](http://msdn.microsoft.com/en-us/library/bb762181(VS.85).aspx). Then we just import it from the Win32 package and it'll work in ghci. Apparently, according to MSDN, this function is technically deprecated, however the replacement [SHGetKnownFolderPath](http://msdn.microsoft.com/en-us/library/bb762188(VS.85).aspx) is only available in Vista and later so we probably need to bind it anyway. Note that `SHGetFolderPath` is in `shell32.dll` except on Windows 2000 which include it in `SHFolder.dll` which come with IE4 and later.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Win32 package should bind SHGetFolderPath","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently Cabal binds this function so that we can find the \"Program Files\" directory on Windows:\r\n\r\n{{{\r\nforeign import stdcall unsafe \"shlobj.h SHGetFolderPathA\"\r\n c_SHGetFolderPath :: Ptr () -> CInt -> Ptr () -> CInt -> CString -> IO CInt\r\n}}}\r\n\r\nThis is fine except that it does not work in ghci because we have no way to tell ghci that it would need to link to `shell32.dll`. As it happens we do not have to tell the static linker to use `shell32.dll` because it appears to link to it by default. This of course means that `runghc Setup` does not work on Windows for Cabal itself which trips up many users. The fact that the `README` tells people to use `ghc --make Setup` instead doesn't help a great deal. See [http://hackage.haskell.org/trac/hackage/ticket/325 Cabal ticket #325]\r\n\r\nWhat would be nice is if the Win32 package would bind [http://msdn.microsoft.com/en-us/library/bb762181(VS.85).aspx SHGetFolderPath]. Then we just import it from the Win32 package and it'll work in ghci. Apparently, according to MSDN, this function is technically deprecated, however the replacement [http://msdn.microsoft.com/en-us/library/bb762188(VS.85).aspx SHGetKnownFolderPath] is only available in Vista and later so we probably need to bind it anyway. Note that `SHGetFolderPath` is in `shell32.dll` except on Windows 2000 which include it in `SHFolder.dll` which come with IE4 and later.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3084alow macros to redefine builtin GHCi commands2019-07-07T19:05:28Zphercekalow macros to redefine builtin GHCi commandsI would like to be able to redefine the builtin GHCi commands. The idea is that when searching for a command the user defined macros would be searched first and only then the built-in commands would be searched. If user wants to invoke a...I would like to be able to redefine the builtin GHCi commands. The idea is that when searching for a command the user defined macros would be searched first and only then the built-in commands would be searched. If user wants to invoke a built-in command regardless of user defined commands he/she would need to start it with two colons (instead of one).
It is an user interface change which may break some scripts, but it would allow to provide different default behavior.\[\[BR\]\]
For example:
- when I use my GHCi extensions I want all my ":continue" commands to be actually something like ":x :continue"
- it would allow to specify different order of searching for abbreviated commands as the default one
- it would allow to specify different default switches for builtin commands (when they have any)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"alow macros to redefine builtin GHCi commands","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I would like to be able to redefine the builtin GHCi commands. The idea is that when searching for a command the user defined macros would be searched first and only then the built-in commands would be searched. If user wants to invoke a built-in command regardless of user defined commands he/she would need to start it with two colons (instead of one).\r\n\r\nIt is an user interface change which may break some scripts, but it would allow to provide different default behavior.[[BR]]\r\nFor example:\r\n * when I use my GHCi extensions I want all my \":continue\" commands to be actually something like \":x :continue\"\r\n * it would allow to specify different order of searching for abbreviated commands as the default one\r\n * it would allow to specify different default switches for builtin commands (when they have any)","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3085warn about language extensions that are not used2022-05-01T11:07:49ZPVerswyvelenwarn about language extensions that are not usedWhen I put
`{-# OPTIONS_GHC -Wall -Werror #-}`
in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file.
For example if I write
`{-# LANGUAGE GeneralizedNewtypeDeriving #-}`
in...When I put
`{-# OPTIONS_GHC -Wall -Werror #-}`
in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file.
For example if I write
`{-# LANGUAGE GeneralizedNewtypeDeriving #-}`
in the file, but I never do newtype deriving, the compiler could give me a warning.
It would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"warn about language extensions that are not used","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["extensions","language","warnings"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When I put\r\n\r\n`{-# OPTIONS_GHC -Wall -Werror #-}`\r\n\r\nin my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file.\r\n\r\nFor example if I write\r\n\r\n`{-# LANGUAGE GeneralizedNewtypeDeriving #-}`\r\n\r\nin the file, but I never do newtype deriving, the compiler could give me a warning.\r\n\r\nIt would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no?\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3086Exception if temp path has national symbols2019-07-07T19:05:28ZTonalException if temp path has national symbolsEnvironment: Windows Vista Home Ru + sp1 ghc 6.10.1
Code for reproduced (file tst.hs):
`/x-haskell
import System.Directory
main = do
cwd <- getTemporaryDirectory
putStrLn cwd
setCurrentDirectory cwd
`
Console session:
```
C:\Lan...Environment: Windows Vista Home Ru + sp1 ghc 6.10.1
Code for reproduced (file tst.hs):
`/x-haskell
import System.Directory
main = do
cwd <- getTemporaryDirectory
putStrLn cwd
setCurrentDirectory cwd
`
Console session:
```
C:\Lang\test\haskell\Тест>ghc --make tst.hs
[1 of 1] Compiling Main ( tst.hs, tst.o )
Linking tst.exe ...
C:\Lang\test\haskell\Тест>set TMP=C:\Lang\test\haskell\Тест
C:\Lang\test\haskell\Тест>tst.exe
C:\Lang\test\haskell\╥хёЄ\
tst.exe: SetCurrentDirectory: does not exist (�5 C405BAO =09B8 C:070==K9 D09;.)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Exception if temp path has national symbols","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Environment: Windows Vista Home Ru + sp1 ghc 6.10.1\r\n\r\nCode for reproduced (file tst.hs):\r\n{{{\r\n#!text/x-haskell\r\nimport System.Directory\r\n\r\nmain = do\r\n cwd <- getTemporaryDirectory\r\n putStrLn cwd\r\n setCurrentDirectory cwd\r\n}}}\r\nConsole session:\r\n{{{\r\nC:\\Lang\\test\\haskell\\Тест>ghc --make tst.hs\r\n[1 of 1] Compiling Main ( tst.hs, tst.o )\r\nLinking tst.exe ...\r\n\r\nC:\\Lang\\test\\haskell\\Тест>set TMP=C:\\Lang\\test\\haskell\\Тест\r\nC:\\Lang\\test\\haskell\\Тест>tst.exe\r\nC:\\Lang\\test\\haskell\\╥хёЄ\\\r\ntst.exe: SetCurrentDirectory: does not exist (\u001d5 C405BAO =09B8 C:070==K9 D09;.)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3087Derived instances of Data lack dataCast1 and dataCast22019-07-07T19:05:28ZdreixelDerived instances of Data lack dataCast1 and dataCast2In the following code snippet:
```
data MyMaybe a = MyNothing | MyJust a deriving (Data, Typeable)
test1 :: ()
test1 = undefined `ext1Q` (\ (Just _) -> ()) $ Just ()
test1' :: ()
test1' = undefined `ext1Q` (\ (MyJust _) -> ()) $ MyJus...In the following code snippet:
```
data MyMaybe a = MyNothing | MyJust a deriving (Data, Typeable)
test1 :: ()
test1 = undefined `ext1Q` (\ (Just _) -> ()) $ Just ()
test1' :: ()
test1' = undefined `ext1Q` (\ (MyJust _) -> ()) $ MyJust ()
```
test1 evaluates to () as expected, but test1' evaluates to bottom.
The same happens for dataypes of kind \* -\> \* -\> \*:
```
newtype Q r a = Q { unQ :: a -> r }
ext2Q :: (Data d, Typeable2 t)
=> (d -> q) -> (forall d1 d2. (Data d1, Data d2) => t d1 d2 -> q) -> d -> q
ext2Q def ext arg =
case dataCast2 (Q ext) of
Just (Q ext') -> ext' arg
Nothing -> def arg
data MyPair a b = MyPair a b deriving (Data, Typeable)
test2 :: ()
test2 = undefined `ext2Q` (\(_,_) -> ()) $ ((),())
test2' :: ()
test2' = undefined `ext2Q` (\(MyPair _ _) -> ()) $ MyPair () ()
```
test2 evaluates to () as expected, but test2' evaluates to bottom. Note that we need to define ext2Q, which uses dataCast2. ext1Q, which is defined in the library, uses dataCast1.
This happens because the derived Data instances for !MyMaybe and !MyPair are missing a definition for dataCast1 and dataCast2, respectively. The Data instances for Maybe and (,) are:
```
instance Data a => Data (Maybe a) where
...
dataCast1 f = gcast1 f
instance (Data a, Data b) => Data (a,b) where
...
dataCast2 f = gcast2 f
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Derived instances of Data lack dataCast1 and dataCast2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following code snippet:\r\n\r\n{{{\r\ndata MyMaybe a = MyNothing | MyJust a deriving (Data, Typeable)\r\n\r\ntest1 :: ()\r\ntest1 = undefined `ext1Q` (\\ (Just _) -> ()) $ Just ()\r\n\r\ntest1' :: ()\r\ntest1' = undefined `ext1Q` (\\ (MyJust _) -> ()) $ MyJust ()\r\n}}}\r\n\r\ntest1 evaluates to () as expected, but test1' evaluates to bottom.\r\n\r\nThe same happens for dataypes of kind * -> * -> *:\r\n{{{\r\nnewtype Q r a = Q { unQ :: a -> r }\r\next2Q :: (Data d, Typeable2 t)\r\n => (d -> q) -> (forall d1 d2. (Data d1, Data d2) => t d1 d2 -> q) -> d -> q\r\next2Q def ext arg =\r\n case dataCast2 (Q ext) of\r\n Just (Q ext') -> ext' arg\r\n Nothing -> def arg\r\n\r\ndata MyPair a b = MyPair a b deriving (Data, Typeable)\r\n\r\ntest2 :: ()\r\ntest2 = undefined `ext2Q` (\\(_,_) -> ()) $ ((),())\r\n\r\ntest2' :: ()\r\ntest2' = undefined `ext2Q` (\\(MyPair _ _) -> ()) $ MyPair () ()\r\n}}}\r\n\r\ntest2 evaluates to () as expected, but test2' evaluates to bottom. Note that we need to define ext2Q, which uses dataCast2. ext1Q, which is defined in the library, uses dataCast1.\r\n\r\nThis happens because the derived Data instances for !MyMaybe and !MyPair are missing a definition for dataCast1 and dataCast2, respectively. The Data instances for Maybe and (,) are:\r\n{{{\r\ninstance Data a => Data (Maybe a) where\r\n ...\r\n dataCast1 f = gcast1 f\r\n\r\ninstance (Data a, Data b) => Data (a,b) where\r\n ...\r\n dataCast2 f = gcast2 f\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3088have ghc-pkg print less useless info when registering2019-07-07T19:05:28Zduncanhave ghc-pkg print less useless info when registeringThis is just the ghc part of [Cabal ticket \#487](http://hackage.haskell.org/trac/hackage/ticket/487), "print less useless info during builds".
```
Useless:
Reading package info from "dist/installed-pkg-config" ... done.
Writing new pa...This is just the ghc part of [Cabal ticket \#487](http://hackage.haskell.org/trac/hackage/ticket/487), "print less useless info during builds".
```
Useless:
Reading package info from "dist/installed-pkg-config" ... done.
Writing new package config file... done.
This message is generated by ghc-pkg. We should patch ghc-pkg to not be so verbose by default. That message is only needed at a higher verbosity level.
```
Actually what's missing is any notion of verbosity in ghc-pkg. It doesn't matter so much what the default verbosity level is as long as Cabal can tell ghc-pkg to be quiet by default. Of course we still want to know about errors, warnings etc.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"have ghc-pkg print less useless info when registering","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is just the ghc part of [http://hackage.haskell.org/trac/hackage/ticket/487 Cabal ticket #487], \"print less useless info during builds\".\r\n\r\n\r\n{{{\r\nUseless:\r\n\r\nReading package info from \"dist/installed-pkg-config\" ... done.\r\nWriting new package config file... done.\r\n\r\nThis message is generated by ghc-pkg. We should patch ghc-pkg to not be so verbose by default. That message is only needed at a higher verbosity level. \r\n}}}\r\n\r\nActually what's missing is any notion of verbosity in ghc-pkg. It doesn't matter so much what the default verbosity level is as long as Cabal can tell ghc-pkg to be quiet by default. Of course we still want to know about errors, warnings etc.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3089Sanity checker false positive (presumably)2019-07-07T19:05:27ZguestSanity checker false positive (presumably)When trying to debug an unrelated problem, I found a Sanity Checker failure. Initially I though this was my bug, but it remained after I left the bug. I stripped the program right down to a minimal example which still causes sanity check...When trying to debug an unrelated problem, I found a Sanity Checker failure. Initially I though this was my bug, but it remained after I left the bug. I stripped the program right down to a minimal example which still causes sanity check failures.
```
import Graphics.Rendering.OpenGL
import Graphics.UI.GLUT
main = do
(progName,args) <- getArgsAndInitialize
createWindow progName
displayCallback $= display
display
display = color $ Color4 1 0 0 (1::GLfloat)
{-
On my machine this reliably trips the sanity checker:
jules$ ghc -debug -fforce-recomp --make sanityminimal.hs && ./sanityminimal +RTS -DS
[1 of 1] Compiling Main ( sanityminimal.hs, sanityminimal.o )
Linking sanityminimal ...
sanityminimal: internal error: ASSERTION FAILED: file Sanity.c, line 241
(GHC version 6.8.3 for i386_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
-}
```
I am running 6.8.3 here but I got someone to test 6.10.1 with the same result.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Sanity checker false positive (presumably)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When trying to debug an unrelated problem, I found a Sanity Checker failure. Initially I though this was my bug, but it remained after I left the bug. I stripped the program right down to a minimal example which still causes sanity check failures.\r\n\r\n{{{\r\nimport Graphics.Rendering.OpenGL\r\nimport Graphics.UI.GLUT\r\n\r\nmain = do\r\n (progName,args) <- getArgsAndInitialize\r\n createWindow progName\r\n displayCallback $= display\r\n display\r\n\r\ndisplay = color $ Color4 1 0 0 (1::GLfloat)\r\n \r\n \r\n{-\r\n\r\nOn my machine this reliably trips the sanity checker:\r\n\r\njules$ ghc -debug -fforce-recomp --make sanityminimal.hs && ./sanityminimal +RTS -DS\r\n[1 of 1] Compiling Main ( sanityminimal.hs, sanityminimal.o )\r\nLinking sanityminimal ...\r\nsanityminimal: internal error: ASSERTION FAILED: file Sanity.c, line 241\r\n\r\n (GHC version 6.8.3 for i386_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\n}}}\r\n\r\nI am running 6.8.3 here but I got someone to test 6.10.1 with the same result.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3090ghc-pkg update should fail if dependent packages might break2019-07-07T19:05:27ZSimon Marlowghc-pkg update should fail if dependent packages might breakIf a package is recompiled and re-installed, and other packages depend on it, those packages might be broken; e.g. see #3060.
Hence `ghc-pkg update` should refuse to perform the update, unless explicitly overridden with `--force`. Howev...If a package is recompiled and re-installed, and other packages depend on it, those packages might be broken; e.g. see #3060.
Hence `ghc-pkg update` should refuse to perform the update, unless explicitly overridden with `--force`. However, it's not quite as simple as that:
- The package might already have been installed over the top of the old one, and
it's too late to reverse that.
- `cabal-install` likes to build and install a bunch of packages at the same time,
using `ghc-pkg update` on each one. This will fail.
- The GHC build system uses `ghc-pkg update` to register packages, and this
breaks when packages are re-built (it's ok for a clean build, though).
I've attached a couple of patches to implement it, but let's hold these back until the above issues are sorted out.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg update should fail if dependent packages might break","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If a package is recompiled and re-installed, and other packages depend on it, those packages might be broken; e.g. see #3060.\r\n\r\nHence `ghc-pkg update` should refuse to perform the update, unless explicitly overridden with `--force`. However, it's not quite as simple as that:\r\n\r\n * The package might already have been installed over the top of the old one, and\r\n it's too late to reverse that.\r\n\r\n * `cabal-install` likes to build and install a bunch of packages at the same time,\r\n using `ghc-pkg update` on each one. This will fail.\r\n\r\n * The GHC build system uses `ghc-pkg update` to register packages, and this\r\n breaks when packages are re-built (it's ok for a clean build, though).\r\n\r\nI've attached a couple of patches to implement it, but let's hold these back until the above issues are sorted out.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/3091With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid l...2019-07-07T19:05:27ZthorkilnaurWith Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'"Running validate on a recent HEAD with
```
$ uname -a
Linux tn14 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
$ python --version
Pyth...Running validate on a recent HEAD with
```
$ uname -a
Linux tn14 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
$ python --version
Python 2.5.1c1
$
```
results in
```
python ../../driver/runtests.py -e ghc_with_native_codegen=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_with_smp=1 --threads=2 --rootdir=. --config=../../config/ghc -e config.confdir=\"../../config\" -e config.compiler=\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/ghc/stage2-inplace/ghc\" -e config.compiler_always_flags.append"(\"\")" -e config.ghc_pkg=\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/utils/ghc-pkg/install-inplace/bin/ghc-pkg\" -e config.hp2ps=\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/utils/hp2ps/hp2ps\" -e config.gs=\"gs\" -e config.platform=\"i386-unknown-linux\" -e config.os=\"linux\" -e config.wordsize=\"32\" -e default_testopts.cleanup=\"1\" -e config.timeout="int() or config.timeout" -e config.timeout_prog=\"../../timeout/install-inplace/bin/timeout\" -e config.exeext=\"\" -e config.top=\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite\" --rootdir=../../../libraries/containers/tests --rootdir=../../../libraries/hpc/tests --rootdir=../../../libraries/bytestring/tests --rootdir=../../../libraries/random/tests --rootdir=../../../libraries/directory/tests --rootdir=../../../libraries/process/tests --rootdir=../../../libraries/Cabal/tests --rootdir=../../../libraries/unix/tests \
\
\
\
\
-e config.fast=1 \
Traceback (most recent call last):
File "../../driver/runtests.py", line 89, in <module>
pat = int(pat)
ValueError: invalid literal for int() with base 10: '1c1'
make[1]: *** [test] Error 1
make[1]: Leaving directory `/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite/tests/ghc-regress'
make: *** [fast] Error 2
make: Leaving directory `/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite/tests/ghc-regress'
-------------------------------------------------------------------
Oops! Looks like you have some unexpected test results or framework failures.
Please fix them before pushing/sending patches.
-------------------------------------------------------------------
```
from code in runtests.py:
```
Wed Jun 11 17:51:48 CEST 2008 Ian Lynagh <igloo@earth.li>
* Refuse to use threads unless python version >= 2.5.2
According to trac #1558, 2.5.2 should work. It's possible a lower bound,
e.g. 2.5, would suffice.
hunk ./driver/runtests.py 13
+import platform> hunk ./driver/runtests.py 83
- config.threads = int(arg)
+ # Trac #1558 says threads don't work in python 2.4.4, but do
+ # in 2.5.2. Probably >= 2.5 is sufficient, but let's be
+ # conservative here.
+ (maj, min, pat) = platform.python_version_tuple()
+ maj = int(maj)
+ min = int(min)
+ pat = int(pat)
+ if (maj, min, pat) >= (2, 5, 2):
+ config.threads = int(arg)
+ else:
+ print "Warning: Ignoring request to use threads as python version < 2.5.2"
```
The problem seems to be the non-decimal digit character in the the python patchlevel `1c1`. I am not sure how to fix this. I seem to recall to have seen non-decimal digit characters also in the minor version string of a python version.
And to be sure: This is not a serious problem for me, it is not preventing me from doing anything important.
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"With Python 2.5.1c1, validate ends \"... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'\"","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running validate on a recent HEAD with\r\n{{{\r\n$ uname -a\r\nLinux tn14 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.8.2\r\n$ python --version\r\nPython 2.5.1c1\r\n$ \r\n}}}\r\nresults in\r\n{{{\r\npython ../../driver/runtests.py -e ghc_with_native_codegen=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_with_smp=1 --threads=2 --rootdir=. --config=../../config/ghc -e config.confdir=\\\"../../config\\\" -e config.compiler=\\\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/ghc/stage2-inplace/ghc\\\" -e config.compiler_always_flags.append\"(\\\"\\\")\" -e config.ghc_pkg=\\\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/utils/ghc-pkg/install-inplace/bin/ghc-pkg\\\" -e config.hp2ps=\\\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/utils/hp2ps/hp2ps\\\" -e config.gs=\\\"gs\\\" -e config.platform=\\\"i386-unknown-linux\\\" -e config.os=\\\"linux\\\" -e config.wordsize=\\\"32\\\" -e default_testopts.cleanup=\\\"1\\\" -e config.timeout=\"int() or config.timeout\" -e config.timeout_prog=\\\"../../timeout/install-inplace/bin/timeout\\\" -e config.exeext=\\\"\\\" -e config.top=\\\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite\\\" --rootdir=../../../libraries/containers/tests --rootdir=../../../libraries/hpc/tests --rootdir=../../../libraries/bytestring/tests --rootdir=../../../libraries/random/tests --rootdir=../../../libraries/directory/tests --rootdir=../../../libraries/process/tests --rootdir=../../../libraries/Cabal/tests --rootdir=../../../libraries/unix/tests \\\r\n \\\r\n \\\r\n \\\r\n \\\r\n -e config.fast=1 \\\r\n\r\nTraceback (most recent call last):\r\n File \"../../driver/runtests.py\", line 89, in <module>\r\n pat = int(pat)\r\nValueError: invalid literal for int() with base 10: '1c1'\r\nmake[1]: *** [test] Error 1\r\nmake[1]: Leaving directory `/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite/tests/ghc-regress'\r\nmake: *** [fast] Error 2\r\nmake: Leaving directory `/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite/tests/ghc-regress'\r\n-------------------------------------------------------------------\r\nOops! Looks like you have some unexpected test results or framework failures.\r\nPlease fix them before pushing/sending patches.\r\n-------------------------------------------------------------------\r\n}}}\r\nfrom code in runtests.py:\r\n{{{\r\nWed Jun 11 17:51:48 CEST 2008 Ian Lynagh <igloo@earth.li>\r\n * Refuse to use threads unless python version >= 2.5.2\r\n According to trac #1558, 2.5.2 should work. It's possible a lower bound,\r\n e.g. 2.5, would suffice.\r\n\r\n hunk ./driver/runtests.py 13\r\n +import platform> hunk ./driver/runtests.py 83\r\n - config.threads = int(arg)\r\n + # Trac #1558 says threads don't work in python 2.4.4, but do\r\n + # in 2.5.2. Probably >= 2.5 is sufficient, but let's be\r\n + # conservative here.\r\n + (maj, min, pat) = platform.python_version_tuple()\r\n + maj = int(maj)\r\n + min = int(min)\r\n + pat = int(pat)\r\n + if (maj, min, pat) >= (2, 5, 2):\r\n + config.threads = int(arg)\r\n + else:\r\n + print \"Warning: Ignoring request to use threads as python version < 2.5.2\"\r\n}}}\r\nThe problem seems to be the non-decimal digit character in the the python patchlevel {{{1c1}}}. I am not sure how to fix this. I seem to recall to have seen non-decimal digit characters also in the minor version string of a python version.\r\n\r\nAnd to be sure: This is not a serious problem for me, it is not preventing me from doing anything important.\r\n\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3092algebraic data types can be extended by data instance declarations2019-07-07T19:05:26ZWolfgang Jeltschalgebraic data types can be extended by data instance declarationsThe following program is accepted by GHC:
```
{-# LANGUAGE TypeFamilies #-}
data T a = C
data instance T Int = CInt
data instance T Bool = CBool
```
I think, it shouldn’t.
<details><summary>Trac metadata</summary>
| Trac field ...The following program is accepted by GHC:
```
{-# LANGUAGE TypeFamilies #-}
data T a = C
data instance T Int = CInt
data instance T Bool = CBool
```
I think, it shouldn’t.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | g9ks157k@acme.softbase.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"algebraic data types can be extended by data instance declarations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["g9ks157k@acme.softbase.org"],"type":"Bug","description":"The following program is accepted by GHC:\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ndata T a = C\r\n\r\ndata instance T Int = CInt\r\n\r\ndata instance T Bool = CBool\r\n}}}\r\nI think, it shouldn’t.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3093-osuf and stub files results in incorrect extension2019-07-07T19:05:26ZNeil Mitchell-osuf and stub files results in incorrect extensionUsing the example from the manual 9.2.1 on stub files:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ ghc --make Foo.hs -fffi -osuf foo.bar
[1 of 1] Compiling Foo ( Foo.hs, Foo.foo.ba...Using the example from the manual 9.2.1 on stub files:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ ghc --make Foo.hs -fffi -osuf foo.bar
[1 of 1] Compiling Foo ( Foo.hs, Foo.foo.bar )
```
This generates the file `Foo.foo_stub.bar`, which is clearly wrong. I'd have expected `Foo_stub.foo.bar`. Note that the command works if no . is placed in the suffix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-osuf and stub files results in incorrect extension","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Using the example from the manual 9.2.1 on stub files:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.1\r\n\r\n$ ghc --make Foo.hs -fffi -osuf foo.bar\r\n[1 of 1] Compiling Foo ( Foo.hs, Foo.foo.bar )\r\n}}}\r\n\r\nThis generates the file {{{Foo.foo_stub.bar}}}, which is clearly wrong. I'd have expected {{{Foo_stub.foo.bar}}}. Note that the command works if no . is placed in the suffix.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3094Some GHC.* module should export word size and heap object header size2019-07-07T19:05:26ZduncanSome GHC.* module should export word size and heap object header sizeSome code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ...Some code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ghc's pinned allocator strategy which has to use a whole number of 4k pages. The magic is in subtracting the heap object header size:
```
-- | Currently set to 32k, less the memory management overhead
defaultChunkSize :: Int
defaultChunkSize = 32 * k - chunkOverhead
where k = 1024
-- | Currently set to 4k, less the memory management overhead
smallChunkSize :: Int
smallChunkSize = 4 * k - chunkOverhead
where k = 1024
-- | The memory management overhead. Currently this is tuned for GHC only.
chunkOverhead :: Int
chunkOverhead = 2 * sizeOf (undefined :: Int)
```
This works for normal builds but for profiling builds it is a couple words off which wastes memory. It would also be be nice if it did not have to use magic constants but if it could import them from `GHC.Exts` or something.
We would want:
- Heap object header size, in words (currently 2 normally or 4 for profiling)
- Word size (4 or 8 bytes)
- Heap block size (currently 4k)
These should all be actual Haskell constants so that they inline perfectly into calculations with no runtime overhead. The heap object header size is obviously different between profiling and normal, however this works out ok because we have to recompile for profiling anyway.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.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":"Some GHC.* module should export word size and heap object header size","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Some code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ghc's pinned allocator strategy which has to use a whole number of 4k pages. The magic is in subtracting the heap object header size:\r\n\r\n{{{\r\n-- | Currently set to 32k, less the memory management overhead\r\ndefaultChunkSize :: Int\r\ndefaultChunkSize = 32 * k - chunkOverhead\r\n where k = 1024\r\n\r\n-- | Currently set to 4k, less the memory management overhead\r\nsmallChunkSize :: Int\r\nsmallChunkSize = 4 * k - chunkOverhead\r\n where k = 1024\r\n\r\n-- | The memory management overhead. Currently this is tuned for GHC only.\r\nchunkOverhead :: Int\r\nchunkOverhead = 2 * sizeOf (undefined :: Int)\r\n}}}\r\n\r\nThis works for normal builds but for profiling builds it is a couple words off which wastes memory. It would also be be nice if it did not have to use magic constants but if it could import them from `GHC.Exts` or something.\r\n\r\nWe would want:\r\n\r\n * Heap object header size, in words (currently 2 normally or 4 for profiling)\r\n * Word size (4 or 8 bytes)\r\n * Heap block size (currently 4k)\r\n\r\nThese should all be actual Haskell constants so that they inline perfectly into calculations with no runtime overhead. The heap object header size is obviously different between profiling and normal, however this works out ok because we have to recompile for profiling anyway.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/3095ghc panic during parsing2019-07-07T19:05:25Zphilip.weaver@gmail.comghc panic during parsingFor the following piece of code
```
class Bla (forall x . x) where
```
the ghc parser yields the appropriate error
```
Forall type not allowed as type parameter
```
However, if you change the code to this
```
class Bla (forall x . x...For the following piece of code
```
class Bla (forall x . x) where
```
the ghc parser yields the appropriate error
```
Forall type not allowed as type parameter
```
However, if you change the code to this
```
class Bla (forall x . x :: *) where
```
Then ghc does this:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
parser/RdrHsSyn.lhs:(525,4)-(548,64): Non-exhaustive patterns in function collect
```
This is reproducible on ghc-6.8.3 and ghc-6.10.1.
I have only tried it on Mac OS X, x86.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic during parsing","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the following piece of code\r\n{{{\r\nclass Bla (forall x . x) where\r\n}}}\r\n\r\nthe ghc parser yields the appropriate error\r\n{{{\r\nForall type not allowed as type parameter\r\n}}}\r\n\r\nHowever, if you change the code to this\r\n{{{\r\nclass Bla (forall x . x :: *) where\r\n}}}\r\n\r\nThen ghc does this:\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tparser/RdrHsSyn.lhs:(525,4)-(548,64): Non-exhaustive patterns in function collect\r\n}}}\r\n\r\nThis is reproducible on ghc-6.8.3 and ghc-6.10.1.\r\n\r\nI have only tried it on Mac OS X, x86.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3096Dead links in GHC documentation2019-07-07T19:05:25ZtibbeDead links in GHC documentationOn http://www.haskell.org/ghc/documentation.html the links to the "(Old) Haskell Libraries" and the "FAQ" are both dead. I assume that the former is irrelevant nowadays. Perhaps the latter should point at http://www.haskell.org/haskellwi...On http://www.haskell.org/ghc/documentation.html the links to the "(Old) Haskell Libraries" and the "FAQ" are both dead. I assume that the former is irrelevant nowadays. Perhaps the latter should point at http://www.haskell.org/haskellwiki/GHC:FAQ ?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.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":"Dead links in GHC documentation","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On http://www.haskell.org/ghc/documentation.html the links to the \"(Old) Haskell Libraries\" and the \"FAQ\" are both dead. I assume that the former is irrelevant nowadays. Perhaps the latter should point at http://www.haskell.org/haskellwiki/GHC:FAQ ?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3097Parser doesn't support doc comments on type aliases2019-07-07T19:05:25ZwaernParser doesn't support doc comments on type aliasesI want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype ...I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype
```
Types with comments are already defined as `ctypedoc` and used for top-level types.
So it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.
The differences are:
- `ctype` disallows foralls/contexts after a contex implication (=\>).
- `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).
- `ctype` allows type equalities (\~) outside contexts. Seems to be disallowed later also.
I haven't seen any further differences (besides comments).
Can I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:
```
(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parser doesn't support doc comments on type aliases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["Haddock"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.\r\n\r\n http://trac.haskell.org/haddock/ticket/9\r\n\r\nIn the parser, the rule for type synonyms is:\r\n{{{\r\n'type' type '=' ctype \r\n}}}\r\n\r\nTypes with comments are already defined as `ctypedoc` and used for top-level types.\r\n\r\nSo it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.\r\n\r\nThe differences are:\r\n\r\n * `ctype` disallows foralls/contexts after a contex implication (=>).\r\n * `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).\r\n * `ctype` allows type equalities (~) outside contexts. Seems to be disallowed later also.\r\n\r\nI haven't seen any further differences (besides comments).\r\n\r\nCan I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:\r\n{{{\r\n(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3098loadObj: failed2019-07-07T19:05:24ZrheinekeloadObj: failedI coded the `PrettyStub.hs` file as shown in the Real World Haskell, page 119 and loaded it into ghci. I then proceeded to follow the examples on page 120:
```
ghci>:load PrettyStub
[2 of 2] Compiling Main ( PrettyStub.hs, i...I coded the `PrettyStub.hs` file as shown in the Real World Haskell, page 119 and loaded it into ghci. I then proceeded to follow the examples on page 120:
```
ghci>:load PrettyStub
[2 of 2] Compiling Main ( PrettyStub.hs, interpreted )
Ok, modules loaded: SimpleJSON, Main.
ghci>:show modules
SimpleJSON ( SimpleJSON.hs, SimpleJSON.o )
Main ( PrettyStub.hs, interpreted )
ghci>:type undefined
undefined :: a
ghci>undefined
*** Exception: Prelude.undefined
ghci>double 3.14
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
loadObj: failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
And now I'm here.6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3099GHCi eats all my memory, even when loading a blank file2019-07-07T19:05:24ZnccbGHCi eats all my memory, even when loading a blank fileMy system is a slightly complicated setup -- I have GHC 6.8.2 installed on my system via my package manager (portage), but I have GHC 6.10.1 installed in my home directory. The system is a x86-64 Gentoo machine, 3GB RAM (plus 2GB swap).
...My system is a slightly complicated setup -- I have GHC 6.8.2 installed on my system via my package manager (portage), but I have GHC 6.10.1 installed in my home directory. The system is a x86-64 Gentoo machine, 3GB RAM (plus 2GB swap).
I can use this system just fine with the ghc executable, building code, running code, installing packages via cabal and so on.
But I went to run ghci earlier, seemingly for the first time. If I run ghci on any file (including a blank .hs file), ghci promptly eats up all my physical RAM and swap (5GB total) and grinds the system to a halt. If I run it with -v5 (or without flags), the last lines are:
```
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
```
I accept this may be an artifact of my odd configuration, but I figure eating 5GB of RAM rather than giving an error message should count as a bug :-) I'm happy to run more tests as necessary.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi eats all my memory, even when loading a blank file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My system is a slightly complicated setup -- I have GHC 6.8.2 installed on my system via my package manager (portage), but I have GHC 6.10.1 installed in my home directory. The system is a x86-64 Gentoo machine, 3GB RAM (plus 2GB swap).\r\n\r\nI can use this system just fine with the ghc executable, building code, running code, installing packages via cabal and so on.\r\n\r\nBut I went to run ghci earlier, seemingly for the first time. If I run ghci on any file (including a blank .hs file), ghci promptly eats up all my physical RAM and swap (5GB total) and grinds the system to a halt. If I run it with -v5 (or without flags), the last lines are:\r\n\r\n{{{\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n}}}\r\n\r\nI accept this may be an artifact of my odd configuration, but I figure eating 5GB of RAM rather than giving an error message should count as a bug :-) I'm happy to run more tests as necessary.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3100GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet2019-07-07T19:05:24ZmightybyteGHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi...```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419
Marked as critical because I haven't found a workaround yet.6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3101GHC crashes on synonym family in a rank-n type2019-07-07T19:05:23ZMartijnVanSteenbergenGHC crashes on synonym family in a rank-n type```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE RankNTypes #-}
module Boom where
type family F a :: *
data Boom = Boom (forall a. F a)
deriving Show
```
When loading the above compilation unit into GHCi, it crashes with:
```
ghc: p...```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE RankNTypes #-}
module Boom where
type family F a :: *
data Boom = Boom (forall a. F a)
deriving Show
```
When loading the above compilation unit into GHCi, it crashes with:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
TcTyFuns.flattenType: synonym family in a rank-n type
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC crashes on synonym family in a rank-n type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n\r\nmodule Boom where\r\n\r\ntype family F a :: *\r\n\r\ndata Boom = Boom (forall a. F a)\r\n deriving Show\r\n}}}\r\n\r\nWhen loading the above compilation unit into GHCi, it crashes with:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tTcTyFuns.flattenType: synonym family in a rank-n type\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3102The impossible happened with implicit parameters2019-07-07T19:05:23ZAshley YakeleyThe impossible happened with implicit parameters```
{-# OPTIONS -XImplicitParams -XRankNTypes #-}
module Bug where
t :: forall a. ((?p :: Int) => a) -> String
t _ = "Hello"
f :: (forall a. a -> String) -> Int
f _ = 3
result :: Int
result = f t
```
```
$ ghc -c Bug.hs
ghc: panic! (...```
{-# OPTIONS -XImplicitParams -XRankNTypes #-}
module Bug where
t :: forall a. ((?p :: Int) => a) -> String
t _ = "Hello"
f :: (forall a. a -> String) -> Int
f _ = 3
result :: Int
result = f t
```
```
$ ghc -c Bug.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The impossible happened with implicit parameters","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# OPTIONS -XImplicitParams -XRankNTypes #-}\r\nmodule Bug where\r\n\r\nt :: forall a. ((?p :: Int) => a) -> String\r\nt _ = \"Hello\"\r\n\r\nf :: (forall a. a -> String) -> Int\r\nf _ = 3\r\n\r\nresult :: Int\r\nresult = f t\r\n}}}\r\n\r\n{{{\r\n$ ghc -c Bug.hs\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for x86_64-unknown-linux):\r\n\tTcTyFuns.flattenType: unexpected PredType\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3103Compiling base with cabal fails.2019-07-07T19:05:22ZLemmihCompiling base with cabal fails.Compiling base with -fext-core fails with ghc-6.10.1 and ghc-6.10.1rc.
Reproduce with: cd libraries/base/ && cabal build -v --ghc-options="-fext-core"
I've attached the output from my machine.
<details><summary>Trac metadata</summary>...Compiling base with -fext-core fails with ghc-6.10.1 and ghc-6.10.1rc.
Reproduce with: cd libraries/base/ && cabal build -v --ghc-options="-fext-core"
I've attached the output from my machine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling base with -fext-core.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling base with -fext-core fails with ghc-6.10.1 and ghc-6.10.1rc.\r\n\r\nReproduce with: cd libraries/base/ && cabal build -v --ghc-options=\"-fext-core\"\r\n\r\nI've attached the output from my machine.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/3104-main-is should be a link time option, not compile time2019-07-07T19:05:22ZNeil Mitchell-main-is should be a link time option, not compile timeThe `-main-is` flag specifies which function name to use as main. However, when doing separate compilation:
```
ghc -c Foo.hs
ghc Foo.o
```
You have to give the `-main-is` in the first step - the compilation, rather than in the second ...The `-main-is` flag specifies which function name to use as main. However, when doing separate compilation:
```
ghc -c Foo.hs
ghc Foo.o
```
You have to give the `-main-is` in the first step - the compilation, rather than in the second step, the linking. It feels like this flag should be a link time option, and would give greater flexibility allowing one object file to be used in multiple projects with different main commands.
If you compile with `ghc --make` this issue isn't really a problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-main-is should be a link time option, not compile time","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The {{{-main-is}}} flag specifies which function name to use as main. However, when doing separate compilation:\r\n\r\n{{{\r\nghc -c Foo.hs\r\nghc Foo.o\r\n}}}\r\n\r\nYou have to give the {{{-main-is}}} in the first step - the compilation, rather than in the second step, the linking. It feels like this flag should be a link time option, and would give greater flexibility allowing one object file to be used in multiple projects with different main commands.\r\n\r\nIf you compile with {{{ghc --make}}} this issue isn't really a problem.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/3105Panic during profiling build after recompiling a dependency with -auto-all2019-07-07T19:05:22ZFSaladPanic during profiling build after recompiling a dependency with -auto-allHi,
I recompiled some dependencies of my project like this (to see more cost centres):
```
cabal install --reinstall --ghc-option=-auto-all OpenGL GLUT ftgl
```
then while trying to recompile my project:
```
cabal clean
cabal install...Hi,
I recompiled some dependencies of my project like this (to see more cost centres):
```
cabal install --reinstall --ghc-option=-auto-all OpenGL GLUT ftgl
```
then while trying to recompile my project:
```
cabal clean
cabal install --enable-library-profiling --enable-executable-profiling --disable-documentation --ghc-options="-O2 -ddump-simpl-stats"
```
the first (non-profiling) build succeeds, but then during the profiling build:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-linux):
applyTypeToArgs
OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.$wa2{v rC2} [gid]
rb{v a1sB8} [lid]
rb1{v a1sB9} [lid]
rb2{v a1sBa} [lid]
rb3{v a1sBb} [lid]
eta{v a1sB4} [lid]
forall a{tv a1sB7} [tv].
(base:GHC.Ptr.Ptr{tc 33A} a{tv a1sB7} [tv]
-> ghc-prim:GHC.Types.Int{(w) tc 3J}
-> base:GHC.IOBase.IO{tc 32I} a{tv a1sB7} [tv])
-> base:GHC.Ptr.Ptr{tc 33A}
(OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.Color3{tc rnw}
a{tv a1sB7} [tv])
-> ghc-prim:GHC.Prim.State#{(w) tc 32q}
ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}
-> (# ghc-prim:GHC.Prim.State#{(w) tc 32q}
ghc-prim:GHC.Prim.RealWorld{(w) tc 31E},
OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.Color3{tc rnw}
a{tv a1sB7} [tv] #)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic during profiling build after recompiling a dependency with -auto-all","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["centres","profiler,profiling,panic,cost"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nI recompiled some dependencies of my project like this (to see more cost centres):\r\n\r\n{{{\r\ncabal install --reinstall --ghc-option=-auto-all OpenGL GLUT ftgl\r\n}}}\r\n\r\nthen while trying to recompile my project:\r\n\r\n{{{\r\ncabal clean\r\ncabal install --enable-library-profiling --enable-executable-profiling --disable-documentation --ghc-options=\"-O2 -ddump-simpl-stats\"\r\n}}}\r\n\r\nthe first (non-profiling) build succeeds, but then during the profiling build:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-unknown-linux):\r\n applyTypeToArgs\r\n OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.$wa2{v rC2} [gid]\r\n rb{v a1sB8} [lid]\r\n rb1{v a1sB9} [lid]\r\n rb2{v a1sBa} [lid]\r\n rb3{v a1sBb} [lid]\r\n eta{v a1sB4} [lid]\r\n forall a{tv a1sB7} [tv].\r\n (base:GHC.Ptr.Ptr{tc 33A} a{tv a1sB7} [tv]\r\n -> ghc-prim:GHC.Types.Int{(w) tc 3J}\r\n -> base:GHC.IOBase.IO{tc 32I} a{tv a1sB7} [tv])\r\n -> base:GHC.Ptr.Ptr{tc 33A}\r\n (OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.Color3{tc rnw}\r\n a{tv a1sB7} [tv])\r\n -> ghc-prim:GHC.Prim.State#{(w) tc 32q}\r\n ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}\r\n -> (# ghc-prim:GHC.Prim.State#{(w) tc 32q}\r\n ghc-prim:GHC.Prim.RealWorld{(w) tc 31E},\r\n OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.Color3{tc rnw}\r\n a{tv a1sB7} [tv] #)\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3106hundred failures of release candidate ghc-6.10.1.20090314 in testsuite2019-07-07T19:05:21ZChristian Maederhundred failures of release candidate ghc-6.10.1.20090314 in testsuiteI've build a working binary distro of ghc-6.10.1.20090314
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-i386-unknown-solaris2.tar.bz2
The testsuite results are in
http:...I've build a working binary distro of ghc-6.10.1.20090314
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-i386-unknown-solaris2.tar.bz2
The testsuite results are in
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-tests.log.fast.gz
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-tests.log.stage2.gz
The summary for "gmake fast" is:
```
OVERALL SUMMARY for test run started at Mon Mar 16 17:47:00 CET 2009
2334 total tests, which gave rise to
12483 test cases, of which
0 caused framework failures
10485 were skipped
1826 expected passes
68 expected failures
0 unexpected passes
104 unexpected failures
```
The log contains 439 lines:
```
/bin/sh: cygpath: not found
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hundred failures of release candidate ghc-6.10.1.20090314 in testsuite","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've build a working binary distro of ghc-6.10.1.20090314\r\n\r\nhttp://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-i386-unknown-solaris2.tar.bz2\r\n\r\nThe testsuite results are in\r\nhttp://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-tests.log.fast.gz\r\nhttp://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1.20090314-tests.log.stage2.gz\r\n\r\nThe summary for \"gmake fast\" is:\r\n{{{\r\nOVERALL SUMMARY for test run started at Mon Mar 16 17:47:00 CET 2009\r\n 2334 total tests, which gave rise to\r\n 12483 test cases, of which\r\n 0 caused framework failures\r\n 10485 were skipped\r\n\r\n 1826 expected passes\r\n 68 expected failures\r\n 0 unexpected passes\r\n 104 unexpected failures\r\n}}}\r\n\r\nThe log contains 439 lines:\r\n{{{\r\n/bin/sh: cygpath: not found\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3107Over-eager GC when blocked on a signal in the non-threaded runtime2019-07-07T19:05:21ZawickOver-eager GC when blocked on a signal in the non-threaded runtimeRight now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal hand...Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting.
It would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dons |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Over-eager GC when blocked on a signal in the non-threaded runtime","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dons"],"type":"Bug","description":"Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting.\r\n\r\nIt would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3108Do a better job of solving recursive type-class constraints with functional d...2019-07-07T19:05:21ZSimon Peyton JonesDo a better job of solving recursive type-class constraints with functional dependenciesThis ticket is just to track this interesting thread on the Haskell list, concerning recursive type-class constraints:
http://www.haskell.org/pipermail/haskell/2009-March/021115.html.
We might want to get back to this when the new constr...This ticket is just to track this interesting thread on the Haskell list, concerning recursive type-class constraints:
http://www.haskell.org/pipermail/haskell/2009-March/021115.html.
We might want to get back to this when the new constraint solver is in place.
The question concerns the interaction of solving recursive type-class constraints, where it is important to aggressively apply functional dependencies. Here's Tom Schrijvers's analysis of Ralf's example:
"The cyclic dictionaries approach is a bit fragile. The problem appears to
be here that GHC alternates exhaustive phases of constraint reduction and
functional dependency improvement. The problem is that in your example you
need both for detecting a cycle.
This can happen:
```
C1 Int
==> 3rd C1 inst
C2 Int y, C1 (y,Bool)
==> 1st C1 inst
C2 Int y, C1 y, C1 Bool
==> 2nd C1 inst
C2 Int y, C1 y
==> 3rd C1 inst
C2 Int y, C2 y z, C1 (z,Bool)
==>
...
```
where all the constraint are different because fresh variables are
introduced.
What you want to happen is:
```
C1 Int
==> 3rd C1 inst
C2 Int y, C1 (y,Bool)
==> 1st C1 inst
C2 Int y, C1 y, C1 Bool
==> 2nd C1 inst
C2 Int y, C1 y
==> C2 FD improvement {Int/y} <<<<
C2 Int Int, C1 Int
==> C1 Int cycle detected
C2 Int Int
==> C2 1st instance
{}
```
It seems that you want improvement to happen at a higher priority than GHC
does now."
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Do a better job of solving recursive type-class constraints with functional dependencies","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This ticket is just to track this interesting thread on the Haskell list, concerning recursive type-class constraints:\r\nhttp://www.haskell.org/pipermail/haskell/2009-March/021115.html.\r\nWe might want to get back to this when the new constraint solver is in place.\r\n\r\nThe question concerns the interaction of solving recursive type-class constraints, where it is important to aggressively apply functional dependencies. Here's Tom Schrijvers's analysis of Ralf's example:\r\n\r\n\"The cyclic dictionaries approach is a bit fragile. The problem appears to\r\nbe here that GHC alternates exhaustive phases of constraint reduction and\r\nfunctional dependency improvement. The problem is that in your example you\r\nneed both for detecting a cycle.\r\n\r\nThis can happen:\r\n{{{\r\n C1 Int\r\n ==> 3rd C1 inst\r\n C2 Int y, C1 (y,Bool)\r\n ==> 1st C1 inst\r\n C2 Int y, C1 y, C1 Bool\r\n ==> 2nd C1 inst\r\n C2 Int y, C1 y\r\n ==> 3rd C1 inst\r\n C2 Int y, C2 y z, C1 (z,Bool)\r\n ==>\r\n ...\r\n}}}\r\nwhere all the constraint are different because fresh variables are\r\nintroduced.\r\n\r\nWhat you want to happen is:\r\n{{{\r\n C1 Int\r\n ==> 3rd C1 inst\r\n C2 Int y, C1 (y,Bool)\r\n ==> 1st C1 inst\r\n C2 Int y, C1 y, C1 Bool\r\n ==> 2nd C1 inst\r\n C2 Int y, C1 y\r\n ==> C2 FD improvement {Int/y} <<<<\r\n C2 Int Int, C1 Int\r\n ==> C1 Int cycle detected\r\n C2 Int Int\r\n ==> C2 1st instance\r\n {}\r\n}}}\r\nIt seems that you want improvement to happen at a higher priority than GHC\r\ndoes now.\"\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/3109GHCi won't start in a x84_64 machine2019-07-07T19:05:20ZguestGHCi won't start in a x84_64 machineI try 'ghci' in command line and it says:
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
ghc: internal error: mmap() returned memory outside 2Gb
(GHC version 6.10.1 for x86_64_unknown_linux)
> Please report this as a ...I try 'ghci' in command line and it says:
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
ghc: internal error: mmap() returned memory outside 2Gb
(GHC version 6.10.1 for x86_64_unknown_linux)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
I'm using it in a "slice" machine, as provided by 'slicehost.com'. It seems to be a virtual server. I can choose my linux distribution, so I choosed 'archlinux' and did 'pacman -Sy' and 'pacman -Su'. Then, 'pacman -Su ghc'.
Also: 'ghc --make' works well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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 won't start in a x84_64 machine","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I try 'ghci' in command line and it says:\r\n\r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nghc: internal error: mmap() returned memory outside 2Gb\r\n (GHC version 6.10.1 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n\r\nI'm using it in a \"slice\" machine, as provided by 'slicehost.com'. It seems to be a virtual server. I can choose my linux distribution, so I choosed 'archlinux' and did 'pacman -Sy' and 'pacman -Su'. Then, 'pacman -Su ghc'.\r\n\r\nAlso: 'ghc --make' works well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3110Setting the hard maximum heap size no longer works2019-07-07T19:05:20ZdonsSetting the hard maximum heap size no longer worksTake this source:
```
main = do print (product [1..])
```
Compile it:
```
$ ghc -O2 A.hs --make -o A -fforce-recomp
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...
```
Set a small maximum heap size, run the program, t...Take this source:
```
main = do print (product [1..])
```
Compile it:
```
$ ghc -O2 A.hs --make -o A -fforce-recomp
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...
```
Set a small maximum heap size, run the program, then kill it after a few seconds:
```
$ time ./A +RTS -M1M -sstderr
./A +RTS -M1M -sstderr
^C 20,177,576 bytes allocated in the heap
32,352 bytes copied during GC
18,840 bytes maximum residency (1 sample(s))
20,888 bytes maximum slop
682 MB total memory in use (116 MB lost due to fragmentation)
Generation 0: 38 collections, 0 parallel, 0.00s, 0.02s elapsed
Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed
INIT time 0.00s ( 0.00s elapsed)
MUT time 4.62s ( 5.24s elapsed)
GC time 0.00s ( 0.02s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 4.62s ( 5.26s elapsed)
%GC time 0.1% (0.4% elapsed)
Alloc rate 4,370,879 bytes per MUT second
Productivity 99.9% of total user, 87.8% of total elapsed
./A +RTS -M1M -sstderr 4.62s user 0.61s system 98% cpu 5.314 total
```
Far more memory has been allocated in the heap than the 1M max limit.
GHC 6.10.1 on Linux x86_64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Setting the hard maximum heap size no longer works","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nTake this source:\r\n\r\n{{{\r\nmain = do print (product [1..])\r\n}}}\r\n\r\nCompile it:\r\n\r\n{{{\r\n$ ghc -O2 A.hs --make -o A -fforce-recomp\r\n[1 of 1] Compiling Main ( A.hs, A.o )\r\nLinking A ...\r\n}}}\r\n\r\nSet a small maximum heap size, run the program, then kill it after a few seconds:\r\n\r\n{{{\r\n$ time ./A +RTS -M1M -sstderr\r\n./A +RTS -M1M -sstderr \r\n^C 20,177,576 bytes allocated in the heap\r\n 32,352 bytes copied during GC\r\n 18,840 bytes maximum residency (1 sample(s))\r\n 20,888 bytes maximum slop\r\n 682 MB total memory in use (116 MB lost due to fragmentation)\r\n\r\n Generation 0: 38 collections, 0 parallel, 0.00s, 0.02s elapsed\r\n Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 4.62s ( 5.24s elapsed)\r\n GC time 0.00s ( 0.02s elapsed)\r\n EXIT time 0.00s ( 0.00s elapsed)\r\n Total time 4.62s ( 5.26s elapsed)\r\n\r\n %GC time 0.1% (0.4% elapsed)\r\n\r\n Alloc rate 4,370,879 bytes per MUT second\r\n\r\n Productivity 99.9% of total user, 87.8% of total elapsed\r\n\r\n\r\n./A +RTS -M1M -sstderr 4.62s user 0.61s system 98% cpu 5.314 total\r\n}}}\r\n\r\nFar more memory has been allocated in the heap than the 1M max limit.\r\n\r\nGHC 6.10.1 on Linux x86_64.","type_of_failure":"OtherFailure","blocking":[]} -->