GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:32:13Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11076Demand information of foreign calls is wrong2019-07-07T18:32:13ZLuite StegemanDemand information of foreign calls is wrongForeign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also c...Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS.
I hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Demand information of foreign calls is wrong","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS.\r\n\r\nI hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/11064Call Arity has the trivial application case wrong2019-07-07T18:32:17ZJoachim Breitnermail@joachim-breitner.deCall Arity has the trivial application case wrongIn `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in
```
let f = ...
in e (f x)
```
we know that f is called at most once, but in
```
let f = ...
in e...In `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in
```
let f = ...
in e (f x)
```
we know that f is called at most once, but in
```
let f = ...
in e f
```
we do not know that.
Previously Call Arity would assume that in `e x`, `x` is evaluated at
most once. This rarely would make a difference (the argument `x` is
analized with an incoming arity of 0, so no eta-expansion would be done
anyways), but of course this should still be fixed.
I just validated a patch and will push shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Call Arity has the trivial application case wrong","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"nomeata"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in\r\n{{{\r\n let f = ...\r\n in e (f x)\r\n}}}\r\nwe know that f is called at most once, but in\r\n{{{\r\n let f = ...\r\n in e f\r\n}}}\r\nwe do not know that.\r\n\r\nPreviously Call Arity would assume that in `e x`, `x` is evaluated at\r\nmost once. This rarely would make a difference (the argument `x` is\r\nanalized with an incoming arity of 0, so no eta-expansion would be done\r\nanyways), but of course this should still be fixed.\r\n\r\nI just validated a patch and will push shortly.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/11055GHC 7.8.4 crash on ARM while building Stack 0.1.72019-07-07T18:32:21ZLokathorGHC 7.8.4 crash on ARM while building Stack 0.1.7I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:
```
daniel@pixie stack $ cabal build
Package has never been configur...I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:
```
daniel@pixie stack $ cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring stack-0.1.7.0...
Building stack-0.1.7.0...
Preprocessing library stack-0.1.7.0...
[ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o )
ghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c
(GHC version 7.8.4 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
```
The folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7.8.4 crash on ARM while building Stack 0.1.7","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:\r\n\r\n{{{\r\ndaniel@pixie stack $ cabal build\r\nPackage has never been configured. Configuring with default flags. If this\r\nfails, please run configure manually.\r\nResolving dependencies...\r\nConfiguring stack-0.1.7.0...\r\nBuilding stack-0.1.7.0...\r\nPreprocessing library stack-0.1.7.0...\r\n[ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o )\r\nghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c\r\n (GHC version 7.8.4 for arm_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n}}}\r\n\r\nThe folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10924Template variable unbound in rewrite rule2019-07-07T18:33:02ZEric CrockettTemplate variable unbound in rewrite ruleThe only ticket I see with this issues that \*isn't\* resolved in 7.10.2 is #10689. Might be a dup.
Compiling with -O1 succeeds, but `ghc -O2` fails:
```
{-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables,
Temp...The only ticket I see with this issues that \*isn't\* resolved in 7.10.2 is #10689. Might be a dup.
Compiling with -O1 succeeds, but `ghc -O2` fails:
```
{-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables,
TemplateHaskell, TypeFamilies, UndecidableInstances #-}
module Bug where
-- needed to use Nat's Num instance for +
import qualified GHC.Num as Num
import Data.Singletons.Prelude
import Data.Singletons.TH
import Data.Type.Natural
import Data.Typeable
-- | Copied from Data.Type.Natural because the data-level version
-- is not exported there.
(<<=) :: Nat -> Nat -> Bool
Z <<= _ = True
S _ <<= Z = False
S n <<= S m = n <<= m
singletons [d|
newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable)
|]
singletons [d|
ppMul :: PrimePower -> [PrimePower] -> [PrimePower]
ppMul x [] = [x]
ppMul x@(PP(p,e)) pps@(PP (p',e'):pps')
| p == p' = PP(p,e Num.+ e'):pps'
| p <<= p' = x:pps
| otherwise = (PP(p',e')):ppMul x pps'
|]
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Template variable unbound in rewrite rule
t_XexU
[t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT,
sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57]
[t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP,
sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88]
[TYPE Let1627437970XSym7
n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5,
TYPE ipv_sfxT,
(SPP
@ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
@ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)
@~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N
((STuple2
@ Nat
@ Nat
@ '(n0_aeyH, n1_aeyI)
@ n0_aeyH
@ n1_aeyI
@~ <'(n0_aeyH, n1_aeyI)>_N
sc_sg53
sc_sg54)
`cast` (sg_sg55
:: R:Sing(,)z '(n0_aeyH, n1_aeyI)
~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))))
`cast` (sg_sg56
:: R:SingPrimePowerz
('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))
~R# Sing
(Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))),
sc_sg57]
[TYPE Let1627437970XSym7
n0_aeyH
n1_aeyI
n0_XeB0
n1_XeB2
ipv_XfzF
(Let1627437970XSym7
n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5)
ipv_sfxT,
TYPE ipv_XfzF,
(SPP
@ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
@ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)
@~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N
((STuple2
@ Nat
@ Nat
@ '(n0_aeyH, n1_aeyI)
@ n0_aeyH
@ n1_aeyI
@~ <'(n0_aeyH, n1_aeyI)>_N
sc_sg53
sc_sg54)
`cast` (Sub (Sym (TFCo:R:Sing(,)z[0] <Nat>_N <Nat>_N)) (Sym
(TFCo:R:Apply(,)kTuple2Sym1l0[0]
<Nat>_N
<Nat>_N
<n1_aeyI>_N
<n0_aeyH>_N)
; (Apply
(Sym
(TFCo:R:Apply(->)kTuple2Sym0l0[0]
<Nat>_N
<Nat>_N
<n0_aeyH>_N))
<n1_aeyI>_N)_N)
:: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI)
~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))))
`cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym
(TFCo:R:ApplyPrimePower(,)PPSym0l0[0]
<(Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI>_N))
:: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))),
ipv_sfxW]
```
I'd love a workaround if possible; I've been unable to find one.7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10904C finalizer may be called on re-used memory2019-07-07T18:33:07ZbherzogC finalizer may be called on re-used memoryIt seems that the runtime system sometimes reuses memory referred to by
`ForeignPtr` values before the associated C finalizers have been run. At
that's what it looks like to me. Maybe I'm interpreting the behavior of
GHC's runtime system...It seems that the runtime system sometimes reuses memory referred to by
`ForeignPtr` values before the associated C finalizers have been run. At
that's what it looks like to me. Maybe I'm interpreting the behavior of
GHC's runtime system incorrectly, or it's a defect in my test program.
To reproduce the defect, compile `finalizertest.hs` and `finalizerlib.c`,
e.g. with
```
ghc finalizertest.hs finalizerlib.c -threaded
```
Run the resulting program as
```
./finalizertest +RTS -N2
```
After a while it prints a message like
```
finalize_value: 80f69dc != 11223344 after 47393 calls
Aborted
```
The C code prints this if the pointer passed to the finalizer does not
point to the expected value.
It's not necessary to link with the threaded runtime, nor is it
necessary to run with more than one CPU. Doing so increases the
likelihood of the defect to occur substantially, though.
I've observed this with several different combinations of GHC and host-systems:
- GHC 7.10.2 on a 64 bit Linux (Debian jessie)
- GHC 7.10.1 on a 32 bit Linux (Debian wheezy)
- GHC 7.4.1 on a 32 bit Linux (Debian wheezy)
This GHC is the one packaged by Debian
It's crucial for the defect that the memory is allocated with
`mallocForeignPtrBytes`. Using `mallocBytes` instead and building a
`ForeignPtr` with `finalizerFree` avoids the defect.
I came across this defect while trying to debug a segmentation fault in
the `zlib` package. This defect was reported on the libraries mailing list
https://mail.haskell.org/pipermail/libraries/2015-June/025829.html
(corresponding Agda ticket: https://github.com/agda/agda/issues/1518). I came across it in one of my own projects last week.
My test program basically does what `zlib` does when allocating
and initializing the `z_stream` value: it allocates memory with
`mallocForeignPtrBytes` and later adds a finalizer with
`addForeignPtrFinalizer`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"C finalizer may be called on re-used memory","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"It seems that the runtime system sometimes reuses memory referred to by\r\n`ForeignPtr` values before the associated C finalizers have been run. At\r\nthat's what it looks like to me. Maybe I'm interpreting the behavior of\r\nGHC's runtime system incorrectly, or it's a defect in my test program.\r\n\r\nTo reproduce the defect, compile `finalizertest.hs` and `finalizerlib.c`,\r\ne.g. with\r\n\r\n{{{\r\nghc finalizertest.hs finalizerlib.c -threaded\r\n}}}\r\n\r\nRun the resulting program as\r\n{{{\r\n./finalizertest +RTS -N2\r\n}}}\r\n\r\nAfter a while it prints a message like\r\n{{{\r\nfinalize_value: 80f69dc != 11223344 after 47393 calls\r\nAborted\r\n}}}\r\n\r\nThe C code prints this if the pointer passed to the finalizer does not\r\npoint to the expected value.\r\n\r\nIt's not necessary to link with the threaded runtime, nor is it\r\nnecessary to run with more than one CPU. Doing so increases the\r\nlikelihood of the defect to occur substantially, though.\r\n\r\nI've observed this with several different combinations of GHC and host-systems:\r\n* GHC 7.10.2 on a 64 bit Linux (Debian jessie)\r\n* GHC 7.10.1 on a 32 bit Linux (Debian wheezy)\r\n* GHC 7.4.1 on a 32 bit Linux (Debian wheezy)\r\n This GHC is the one packaged by Debian\r\n\r\nIt's crucial for the defect that the memory is allocated with\r\n`mallocForeignPtrBytes`. Using `mallocBytes` instead and building a\r\n`ForeignPtr` with `finalizerFree` avoids the defect.\r\n\r\nI came across this defect while trying to debug a segmentation fault in\r\nthe `zlib` package. This defect was reported on the libraries mailing list\r\nhttps://mail.haskell.org/pipermail/libraries/2015-June/025829.html\r\n(corresponding Agda ticket: https://github.com/agda/agda/issues/1518). I came across it in one of my own projects last week.\r\n\r\nMy test program basically does what `zlib` does when allocating\r\nand initializing the `z_stream` value: it allocates memory with\r\n`mallocForeignPtrBytes` and later adds a finalizer with\r\n`addForeignPtrFinalizer`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10899Polytype accepted in RHS of default associated type2019-07-07T18:33:08ZRichard Eisenbergrae@richarde.devPolytype accepted in RHS of default associated typeThis hogwash is accepted:
```
class C a where
type F a
type F a = forall m. m a
```
I will fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Versi...This hogwash is accepted:
```
class C a where
type F a
type F a = forall m. m a
```
I will fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Polytype accepted in RHS of default associated type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This hogwash is accepted:\r\n\r\n{{{\r\nclass C a where\r\n type F a\r\n type F a = forall m. m a\r\n}}}\r\n\r\nI will fix.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/10882Fix target triple for Arm2019-07-07T18:33:13ZerikdFix target triple for ArmLLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float.
Clang on the other hand generates IR code with a target triple of "ar...LLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float.
Clang on the other hand generates IR code with a target triple of "armv6-linux-gnueablhf" which is ARMv6 and hardware float so it works on the original Raspberry Pi.
GHC should either use the same target triple as Clang or at least make it configurable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix target tripe for Arm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"LLVM IR code generated by GHC on Arm (Debian) uses a target triple of \"arm-linux-gnueabi\" which according the LLVM people is something like ARMv4 with software float.\r\n\r\nClang on the other hand generates IR code with a target triple of \"armv6-linux-gnueablhf\" which is ARMv6 and hardware float so it works on the original Raspberry Pi.\r\n\r\nGHC should either use the same target triple as Clang or at least make it configurable.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10879base is not included in the haddock index2019-07-07T18:33:15ZFeuerbachbase is not included in the haddock indexIt appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc.
```
% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html
1
% grep -c base ~/.st...It appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc.
```
% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html
1
% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.10.2/share/doc/ghc/html/libraries/index.html
0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| 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":"base is not included in the haddock index","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc.\r\n\r\n{{{\r\n% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html\r\n1\r\n\r\n% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.10.2/share/doc/ghc/html/libraries/index.html\r\n0\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10870PPC.Ppr: Shift by 32 bits is not allowed.2019-07-07T18:33:24ZJoachim Breitnermail@joachim-breitner.dePPC.Ppr: Shift by 32 bits is not allowed.Hi,
when compiling `vector-algorithms` on powerpc, I get
```
[ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist-ghc/build/Data/Vector/Algorithms/Tim.o )
ghc: panic! (the 'impossible' happened)
(...Hi,
when compiling `vector-algorithms` on powerpc, I get
```
[ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist-ghc/build/Data/Vector/Algorithms/Tim.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for powerpc-unknown-linux):
PPC.Ppr: Shift by 32 bits is not allowed.
```
I do not get this error on other 32bit architectures.
The offending code seems to be
```
minrun :: Int -> Int
minrun n0 = (n0 `unsafeShiftR` extra) + if (lowMask .&. n0) > 0 then 1 else 0
where
-- smear the bits down from the most significant bit
!n1 = n0 .|. unsafeShiftR n0 1
!n2 = n1 .|. unsafeShiftR n1 2
!n3 = n2 .|. unsafeShiftR n2 4
!n4 = n3 .|. unsafeShiftR n3 8
!n5 = n4 .|. unsafeShiftR n4 16
!n6 = n5 .|. unsafeShiftR n5 32
```
The call to panic was introduced by Erik in the fix for #5900.
Is the code at fault, or the compiler?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PPC.Ppr: Shift by 32 bits is not allowed.","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd"],"type":"Bug","description":"Hi,\r\n\r\nwhen compiling `vector-algorithms` on powerpc, I get\r\n{{{\r\n[ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist-ghc/build/Data/Vector/Algorithms/Tim.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for powerpc-unknown-linux):\r\n\tPPC.Ppr: Shift by 32 bits is not allowed.\r\n}}}\r\n\r\nI do not get this error on other 32bit architectures.\r\n\r\nThe offending code seems to be\r\n{{{\r\nminrun :: Int -> Int\r\nminrun n0 = (n0 `unsafeShiftR` extra) + if (lowMask .&. n0) > 0 then 1 else 0\r\n where\r\n -- smear the bits down from the most significant bit\r\n !n1 = n0 .|. unsafeShiftR n0 1\r\n !n2 = n1 .|. unsafeShiftR n1 2\r\n !n3 = n2 .|. unsafeShiftR n2 4\r\n !n4 = n3 .|. unsafeShiftR n3 8\r\n !n5 = n4 .|. unsafeShiftR n4 16\r\n !n6 = n5 .|. unsafeShiftR n5 32\r\n}}}\r\n\r\nThe call to panic was introduced by Erik in the fix for #5900.\r\n\r\nIs the code at fault, or the compiler?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10855GHC rejects code that Haskell 2010 report accepts2019-07-07T18:33:28ZRichard Eisenbergrae@richarde.devGHC rejects code that Haskell 2010 report acceptsAccording to [The Haskell 2010 Report](https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003), the following two modules should compile. But they don't, failing with parse errors:
```
{-# LANGUAGE Haskell2010 #-}
m...According to [The Haskell 2010 Report](https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003), the following two modules should compile. But they don't, failing with parse errors:
```
{-# LANGUAGE Haskell2010 #-}
module Bug where
bool = - case b of False -> 0; True -> (-1)
```
```
{-# LANGUAGE Haskell2010 #-}
instance Num (IO a) where
negate = id
main = - do putStrLn "hi!"
```
Note the unary `-` signs.
I'm not sure whether we should complicate the parser to fix these, but we should document the compliance-failure in the manual.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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 rejects code that Haskell 2010 report accepts","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 The Haskell 2010 Report], the following two modules should compile. But they don't, failing with parse errors:\r\n\r\n{{{\r\n{-# LANGUAGE Haskell2010 #-}\r\n\r\nmodule Bug where\r\n\r\nbool = - case b of False -> 0; True -> (-1)\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE Haskell2010 #-}\r\n\r\ninstance Num (IO a) where\r\n negate = id\r\n\r\nmain = - do putStrLn \"hi!\"\r\n}}}\r\n\r\nNote the unary `-` signs.\r\n\r\nI'm not sure whether we should complicate the parser to fix these, but we should document the compliance-failure in the manual.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10817Looping default associated type family without UndecidableInstances2019-07-07T18:33:45ZRichard Eisenbergrae@richarde.devLooping default associated type family without UndecidableInstancesWhen I say
```
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Proxy
class C a where
type F a
type F a = F a
instance C Bool
x :: Proxy (F Bool)
x = Proxy
```
GHC just loops. Setting a low `-ftype-function-depth` do...When I say
```
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Proxy
class C a where
type F a
type F a = F a
instance C Bool
x :: Proxy (F Bool)
x = Proxy
```
GHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Looping default associated type family without UndecidableInstances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nmodule Bug where\r\n\r\nimport Data.Proxy\r\n\r\nclass C a where\r\n type F a\r\n type F a = F a\r\n\r\ninstance C Bool\r\n\r\nx :: Proxy (F Bool)\r\nx = Proxy\r\n}}}\r\n\r\nGHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10810Data constructor operators mis-printed in Template Haskell2019-07-07T18:33:46ZRichard Eisenbergrae@richarde.devData constructor operators mis-printed in Template HaskellWhen I say
```
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-}
module Bug where
$([d| data Foo = (:!) |])
```
I get
```
Bug.hs:6:3-24: Splicing declarations
[d| data Foo = :! |] ======> dat...When I say
```
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-}
module Bug where
$([d| data Foo = (:!) |])
```
I get
```
Bug.hs:6:3-24: Splicing declarations
[d| data Foo = :! |] ======> data Foo = :!
```
There are missing parentheses in that output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data constructor operators mis-printed in Template Haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-}\r\n\r\nmodule Bug where\r\n\r\n$([d| data Foo = (:!) |])\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\nBug.hs:6:3-24: Splicing declarations\r\n [d| data Foo = :! |] ======> data Foo = :!\r\n}}}\r\n\r\nThere are missing parentheses in that output.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10795Upgrade gcc in 7.102019-07-07T18:33:50Zjoozek78Upgrade gcc in 7.10See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [this mail thread](http://sourceforge.net/p/mingw-w64/mailman/message/29339395/)). That's because response files ar...See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [this mail thread](http://sourceforge.net/p/mingw-w64/mailman/message/29339395/)). That's because response files are not used properly by older gcc.
**gcc was upgraded for 7.12 in #10726 so this just needs to be backported**
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Upgrade gcc in 7.10","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [[http://sourceforge.net/p/mingw-w64/mailman/message/29339395/|this mail thread]]). That's because response files are not used properly by older gcc.\r\n\r\n'''gcc was upgraded for 7.12 in #10726 so this just needs to be backported'''","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10772Type operator variable in prefix notation fails2019-07-07T18:33:57ZJoachim Breitnermail@joachim-breitner.deType operator variable in prefix notation failsHi,
I’m not sure if this is me misreading the documentation at https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/data-type-extensions.html\#infix-tycons (in which case maybe the wording can be improved) or an actual bug. ...Hi,
I’m not sure if this is me misreading the documentation at https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/data-type-extensions.html\#infix-tycons (in which case maybe the wording can be improved) or an actual bug. But I would have expected this code
```
foo :: [(*)] -> Maybe (*)
foo _ = Nothing
```
to be equivalent to
```
foo :: [a] -> Maybe a
foo _ = Nothing
```
at least with `-XNoTypeOperators`. But independent of that flag, with GHC HEAD and 7.8, I get
```
/tmp/foo.hs:1:9: error: Not in scope: type constructor or class ‘*’
```7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10745Error in fusion when compiling Data.Yaml2020-05-08T14:23:22ZnclarkeError in fusion when compiling Data.Yaml```
[2 of 7] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, dist/dist-sandbox-b22ce51e/build/Data/Yaml/Internal.o )
Data/Yaml/Internal.hs:28:1: Warning:
The import of ‘Control.Applicative’ is redundant
except perhaps to...```
[2 of 7] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, dist/dist-sandbox-b22ce51e/build/Data/Yaml/Internal.o )
Data/Yaml/Internal.hs:28:1: Warning:
The import of ‘Control.Applicative’ is redundant
except perhaps to import instances from ‘Control.Applicative’
To import instances alone, use: import Control.Applicative()
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Tick in rule
unstream
@ a34_ayco
@ Void
@ m_aycm
@ b_aycn
(ConduitWithStream
@ a34_ayco
@ Void
@ m_aycm
@ b_aycn
(let {
$dApplicative_aycu :: Applicative (ConduitM a34_ayco Void m_aycm)
[LclId, Str=DmdType]
$dApplicative_aycu =
$fApplicativeConduitM
@ a34_ayco
@ Void
@ m_aycm
($fFunctorConduitM @ a34_ayco @ Void @ m_aycm) } in
letrec {
loop_aycv :: b_aycn -> ConduitM a34_ayco Void m_aycm b_aycn
[LclId, Arity=1, Str=DmdType]
loop_aycv =
\ (accum_aycw :: b_aycn) ->
$fMonadConduitM_$c>>=
@ a34_ayco
@ Void
@ m_aycm
$dApplicative_aycu
@ (Maybe a34_ayco)
@ b_aycn
((await @ a34_ayco @ m_aycm $dMonad1_aycq) @ Void)
(maybe
@ (ConduitM a34_ayco Void m_aycm b_aycn)
@ a34_ayco
($fMonadConduitM_$creturn
@ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn accum_aycw)
(\ (a35_aycx :: a34_ayco) ->
$fMonadConduitM_$c>>=
@ a34_ayco
@ Void
@ m_aycm
$dApplicative_aycu
@ b_aycn
@ b_aycn
($ @ (m_aycm b_aycn)
@ (ConduitM a34_ayco Void m_aycm b_aycn)
($fMonadBasebaseConduitM_$clift
@ a34_ayco @ Void @ m_aycm @ b_aycn $dMonad1_aycq)
(f_aycs accum_aycw a35_aycx))
(\ (accum'_aycy :: b_aycn) ->
case accum'_aycy of wild_aycz { __DEFAULT ->
loop_aycv wild_aycz
}))); } in
loop_aycv b1_ayct)
(foldMS
@ b_aycn @ a34_ayco @ m_aycm $dMonad1_aycq f_aycs b1_ayct @ Void))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Error in fusion when compiling Data.Yaml","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\n[2 of 7] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, dist/dist-sandbox-b22ce51e/build/Data/Yaml/Internal.o )\r\n\r\nData/Yaml/Internal.hs:28:1: Warning:\r\n The import of ‘Control.Applicative’ is redundant\r\n except perhaps to import instances from ‘Control.Applicative’\r\n To import instances alone, use: import Control.Applicative()\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n Tick in rule\r\n unstream\r\n @ a34_ayco\r\n @ Void\r\n @ m_aycm\r\n @ b_aycn\r\n (ConduitWithStream\r\n @ a34_ayco\r\n @ Void\r\n @ m_aycm\r\n @ b_aycn\r\n (let {\r\n $dApplicative_aycu :: Applicative (ConduitM a34_ayco Void m_aycm)\r\n [LclId, Str=DmdType]\r\n $dApplicative_aycu =\r\n $fApplicativeConduitM\r\n @ a34_ayco\r\n @ Void\r\n @ m_aycm\r\n ($fFunctorConduitM @ a34_ayco @ Void @ m_aycm) } in\r\n letrec {\r\n loop_aycv :: b_aycn -> ConduitM a34_ayco Void m_aycm b_aycn\r\n [LclId, Arity=1, Str=DmdType]\r\n loop_aycv =\r\n \\ (accum_aycw :: b_aycn) ->\r\n $fMonadConduitM_$c>>=\r\n @ a34_ayco\r\n @ Void\r\n @ m_aycm\r\n $dApplicative_aycu\r\n @ (Maybe a34_ayco)\r\n @ b_aycn\r\n ((await @ a34_ayco @ m_aycm $dMonad1_aycq) @ Void)\r\n (maybe\r\n @ (ConduitM a34_ayco Void m_aycm b_aycn)\r\n @ a34_ayco\r\n ($fMonadConduitM_$creturn\r\n @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn accum_aycw)\r\n (\\ (a35_aycx :: a34_ayco) ->\r\n $fMonadConduitM_$c>>=\r\n @ a34_ayco\r\n @ Void\r\n @ m_aycm\r\n $dApplicative_aycu\r\n @ b_aycn\r\n @ b_aycn\r\n ($ @ (m_aycm b_aycn)\r\n @ (ConduitM a34_ayco Void m_aycm b_aycn)\r\n ($fMonadBasebaseConduitM_$clift\r\n @ a34_ayco @ Void @ m_aycm @ b_aycn $dMonad1_aycq)\r\n (f_aycs accum_aycw a35_aycx))\r\n (\\ (accum'_aycy :: b_aycn) ->\r\n case accum'_aycy of wild_aycz { __DEFAULT ->\r\n loop_aycv wild_aycz\r\n }))); } in\r\n loop_aycv b1_ayct)\r\n (foldMS\r\n @ b_aycn @ a34_ayco @ m_aycm $dMonad1_aycq f_aycs b1_ayct @ Void))\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10715Possible regression in Coercible a (X a) between 7.8 and 7.102019-07-07T18:34:24ZinakiPossible regression in Coercible a (X a) between 7.8 and 7.10In upgrading to7.10, code of the form
```hs
{-# LANGUAGE FlexibleContexts #-}
import Data.Coerce (coerce, Coercible)
data X a
doCoerce :: Coercible a (X a) => a -> X a
doCoerce = coerce
```
fails to compile in 7.10.1 and 7.10.2 with ...In upgrading to7.10, code of the form
```hs
{-# LANGUAGE FlexibleContexts #-}
import Data.Coerce (coerce, Coercible)
data X a
doCoerce :: Coercible a (X a) => a -> X a
doCoerce = coerce
```
fails to compile in 7.10.1 and 7.10.2 with the error
```
testCoerce.hs:6:13:
Could not deduce (a ~ X a)
from the context (Coercible a (X a))
bound by the type signature for
doCoerce :: Coercible a (X a) => a -> X a
at testCoerce.hs:6:13-41
‘a’ is a rigid type variable bound by
the type signature for doCoerce :: Coercible a (X a) => a -> X a
at testCoerce.hs:6:13
Relevant role signatures: type role X phantom
In the ambiguity check for the type signature for ‘doCoerce’:
doCoerce :: forall a. Coercible a (X a) => a -> X a
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature for ‘doCoerce’:
doCoerce :: Coercible a (X a) => a -> X a
```
while it works in 7.8.4.
Surprisingly (to me at least), the code works in 7.10.1 and 7.10.2 if I change it to
```hs
{-# LANGUAGE FlexibleContexts #-}
import Data.Coerce (coerce, Coercible)
data X a
doCoerce :: Coercible a (X b) => a -> X a
doCoerce = coerce
```
while it fails to compile in 7.8.4 with the error
```
testCoerce.hs:6:13:
Could not coerce from ‘a’ to ‘X b0’
because ‘a’ and ‘X b0’ are different types.
arising from the ambiguity check for ‘doCoerce’
from the context (Coercible a (X b))
bound by the type signature for
doCoerce :: Coercible a (X b) => a -> X a
at testCoerce.hs:6:13-41
The type variable ‘b0’ is ambiguous
In the ambiguity check for:
forall a b. Coercible a (X b) => a -> X a
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature for ‘doCoerce’:
doCoerce :: Coercible a (X b) => a -> X a
```
The coercion pattern may look a bit funny, but it is rather useful when one has newtypes of the form
```hs
newtype Y = Y (ForeignPtr Y)
```
which appear naturally when writing bindings to C libraries, and one wants to get access to the underlying ForeignPtr from Y (here X is ForeignPtr). The relevant Coercible instance here is Coercible Y (ForeignPtr Y), as above.
I would have expected the version with context "Coercible a (X a)" to be accepted, as 7.8.4 does, since it seems to be a specialization of the more general coerce, but maybe I am missing something?7.10.3Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/10713Type family not reducing over data family2019-07-07T18:34:28ZacowleyType family not reducing over data familyGiven this code,
```
type family TEq t s where
TEq t t = 'True
TEq t s = 'False
data family T a
```
I expected this GHCi interaction to reduce:
`:kind! TEq (T Int) (T Bool)`
But it does not. It does reduce (to `'True`) if you inst...Given this code,
```
type family TEq t s where
TEq t t = 'True
TEq t s = 'False
data family T a
```
I expected this GHCi interaction to reduce:
`:kind! TEq (T Int) (T Bool)`
But it does not. It does reduce (to `'True`) if you instead ask,
`:kind! TEq (T Int) (T Int)`
Tested on GHC 7.10.2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.2 |
| 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":"Type family not reducing over data family","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given this code,\r\n\r\n{{{\r\ntype family TEq t s where\r\n TEq t t = 'True\r\n TEq t s = 'False\r\ndata family T a\r\n}}}\r\n\r\nI expected this GHCi interaction to reduce:\r\n`:kind! TEq (T Int) (T Bool)`\r\n\r\nBut it does not. It does reduce (to `'True`) if you instead ask,\r\n\r\n`:kind! TEq (T Int) (T Int)`\r\n\r\nTested on GHC 7.10.2\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/10700include/stg/Prim.h isn't C++ compatible2019-07-07T18:34:35ZFabianinclude/stg/Prim.h isn't C++ compatibleStgWord hs_cmpxchg8(volatile StgWord8 \*x, StgWord old, StgWord new);
and a few other declarations in Prim.h causes problems as they use *new* as a variable name.
<details><summary>Trac metadata</summary>
| Trac field | Va...StgWord hs_cmpxchg8(volatile StgWord8 \*x, StgWord old, StgWord new);
and a few other declarations in Prim.h causes problems as they use *new* as a variable name.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"include/stg/Prim.h isn't C++ compatible","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["FFI"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"StgWord hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new);\r\n\r\nand a few other declarations in Prim.h causes problems as they use ''new'' as a variable name.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3rasenrasenhttps://gitlab.haskell.org/ghc/ghc/-/issues/10668Missing brackets in import hint with TypeOperators2019-07-07T18:34:44ZBen PriceMissing brackets in import hint with TypeOperators```hs
import Data.Type.Equality(Refl)
```
errors with
```
error:
In module ‘Data.Type.Equality’:
‘Refl’ is a data constructor of ‘:~:’
To import it use
‘import’ Data.Type.Equality( :~:( Refl ) )
or
‘import...```hs
import Data.Type.Equality(Refl)
```
errors with
```
error:
In module ‘Data.Type.Equality’:
‘Refl’ is a data constructor of ‘:~:’
To import it use
‘import’ Data.Type.Equality( :~:( Refl ) )
or
‘import’ Data.Type.Equality( :~:(..) )
```
But the code there does not parse, one needs
```hs
import Data.Type.Equality((:~:)(Refl))
```
instead (note the extra brackets!).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Missing brackets in import hint with TypeOperators","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nimport Data.Type.Equality(Refl)\r\n}}}\r\nerrors with\r\n{{{\r\nerror:\r\n In module ‘Data.Type.Equality’:\r\n ‘Refl’ is a data constructor of ‘:~:’\r\n To import it use\r\n ‘import’ Data.Type.Equality( :~:( Refl ) )\r\n or\r\n ‘import’ Data.Type.Equality( :~:(..) )\r\n}}}\r\nBut the code there does not parse, one needs\r\n{{{#!hs\r\nimport Data.Type.Equality((:~:)(Refl))\r\n}}}\r\ninstead (note the extra brackets!).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3thomaswthomaswhttps://gitlab.haskell.org/ghc/ghc/-/issues/10667'-g' option generates invalid assembly when '*/*' operator is used2019-07-07T18:34:44ZSergei Trofimovich'-g' option generates invalid assembly when '*/*' operator is usedBug is observed when building cpphs-1.19
```hs
module A where
x */* y = 42
```
```
$ ghc -fforce-recomp A -g
[1 of 1] Compiling A ( A.hs, A.o )
/tmp/ghc23923_0/ghc_2.s: Assembler messages:
/tmp/ghc23923_0/ghc_2.s:17:0:...Bug is observed when building cpphs-1.19
```hs
module A where
x */* y = 42
```
```
$ ghc -fforce-recomp A -g
[1 of 1] Compiling A ( A.hs, A.o )
/tmp/ghc23923_0/ghc_2.s: Assembler messages:
/tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression
/tmp/ghc23923_0/ghc_2.s:17:0:
Warning: missing operand; zero assumed
...
```
The problem here is the following assembly snippet:
```
.text
.align 8
.loc 1 3 1 /* */* */
.quad 12884901911
.quad 0
.quad 15
```
Would it be worthwile using ';' as a comment instead?
Don't know if it's universally portable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.10.2-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | scpmw |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"'-g' option generates invalid assembly when '*/*' operator is used","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":["scpmw"],"type":"Bug","description":"Bug is observed when building cpphs-1.19\r\n\r\n{{{#!hs\r\nmodule A where\r\n\r\nx */* y = 42\r\n}}}\r\n\r\n{{{\r\n$ ghc -fforce-recomp A -g\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n/tmp/ghc23923_0/ghc_2.s: Assembler messages:\r\n\r\n/tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression\r\n\r\n/tmp/ghc23923_0/ghc_2.s:17:0:\r\n Warning: missing operand; zero assumed\r\n...\r\n}}}\r\n\r\nThe problem here is the following assembly snippet:\r\n{{{\r\n.text\r\n .align 8\r\n .loc 1 3 1 /* */* */\r\n .quad 12884901911\r\n .quad 0\r\n .quad 15\r\n\r\n}}}\r\n\r\nWould it be worthwile using ';' as a comment instead?\r\nDon't know if it's universally portable.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3