GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:13:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15284Can't parse ''(*) in GHC HEAD2019-07-07T18:13:27ZRyan ScottCan't parse ''(*) in GHC HEADI can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails):
```
$ /opt/ghc/8.4.3/bin/ghci...I can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails):
```
$ /opt/ghc/8.4.3/bin/ghci -XTemplateHaskell
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> import GHC.TypeNats
λ> ''(*)
GHC.TypeNats.*
```
```
$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTemplateHaskell
GHCi, version 8.5.20180617: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> import GHC.TypeNats
λ> ''(*)
<interactive>:2:4: error: parse error on input ‘*’
```
int-index, I believe this was caused by your commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60 (`Embrace -XTypeInType, add -XStarIsType`). Do you know what is going on here?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | int-index |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't parse ''(*) in GHC HEAD","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["int-index"],"type":"Bug","description":"I can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails):\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghci -XTemplateHaskell\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> import GHC.TypeNats\r\nλ> ''(*)\r\nGHC.TypeNats.*\r\n}}}\r\n\r\n{{{\r\n$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTemplateHaskell \r\nGHCi, version 8.5.20180617: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> import GHC.TypeNats\r\nλ> ''(*)\r\n\r\n<interactive>:2:4: error: parse error on input ‘*’\r\n}}}\r\n\r\nint-index, I believe this was caused by your commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60 (`Embrace -XTypeInType, add -XStarIsType`). Do you know what is going on here?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15300Unboxed Sums Crash2019-07-07T18:13:22ZAndrew MartinUnboxed Sums CrashI've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC ...I've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC 8.4.3), do the following:
```
git clone https://github.com/andrewthad/packed
cd packed
cabal new-build
```
We use `cabal new-build` for its side effect of creating a `.ghc.environment.xyz` file. Now, create a minimal example in the directory called `eol.hs` with the following contents:
```hs
import Packed.Bytes.Parser (Parser)
import Data.Word
import Packed.Bytes (Bytes)
import GHC.Exts (RealWorld)
import Packed.Bytes.Stream.IO (ByteStream)
import qualified Packed.Bytes as B
import qualified Data.Char
import qualified Packed.Bytes.Parser as P
import qualified Packed.Bytes.Stream.IO as Stream
main :: IO ()
main = do
r <- runExampleParser
( do P.takeBytesUntilEndOfLineConsume
P.takeBytesUntilEndOfLineConsume
P.takeBytesUntilEndOfLineConsume
) (foldMap Stream.singleton (map charToWord8 "the\nemporium\rhas\narrived"))
print r
runExampleParser :: Parser e () a -> ByteStream RealWorld -> IO (Maybe a, Maybe String)
runExampleParser parser stream = do
P.Result mleftovers r _ <- P.parseStreamIO stream () parser
mextra <- case mleftovers of
Nothing -> return Nothing
Just (P.Leftovers chunk remainingStream) -> do
bs <- Stream.unpack remainingStream
return (Just (map word8ToChar (B.unpack chunk ++ bs)))
return (either (const Nothing) Just r,mextra)
word8ToChar :: Word8 -> Char
word8ToChar = Data.Char.chr . fromIntegral
charToWord8 :: Char -> Word8
charToWord8 = fromIntegral . Data.Char.ord
s2b :: String -> Bytes
s2b = B.pack . map charToWord8
c2w :: Char -> Word8
c2w = charToWord8
```
Finally, build this with `ghc -O2 eol.hs`, and then run the executable this produces to get the following:
```
(Nothing,Just "\rhas\narrived")
eol: internal error: stg_ap_n_ret
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
Things worth noting:
1. I think the program fails in the final GC that runs right before the program terminates. We can see that it produces a correct result of `(Nothing,Just "\rhas\narrived")`, but something on the heap has definitely been corrupted.
1. This only happens with `-O2` turned on.
1. This only happens when the parser does not successfully parse its input.
Here's some more context around this. I've been working on a parser that uses unboxed sums instead of continuations. After #15038 was fixed, everything had been going well. Then, I took the parser type and added two things to it: (1) context and (2) typed errors. Context is basically like throwing `StateT` on top and errors are like throwing `ExceptT` on top. After this, everything in my test suite kept working except for a single test, which now consistently crashes my test suite. So, I originally had this:
```hs
type Bytes# = (# ByteArray#, Int#, Int# #)
type Maybe# (a :: TYPE r) = (# (# #) | a #)
type Leftovers# s = (# Bytes# , ByteStream s #)
type Result# s (r :: RuntimeRep) (a :: TYPE r) =
(# Maybe# (Leftovers# s), Maybe# a #)
newtype ParserLevity (r :: RuntimeRep) (a :: TYPE r) = ParserLevity
{ getParserLevity :: forall s.
Maybe# (Leftovers# s)
-> State# s
-> (# State# s, Result# s r a #)
}
```
But I changed it to this:
```hs
type Bytes# = (# ByteArray#, Int#, Int# #)
type Maybe# (a :: TYPE r) = (# (# #) | a #)
type Either# a (b :: TYPE r) = (# a | b #)
type Leftovers# s = (# Bytes# , ByteStream s #)
type Result# e c s (r :: RuntimeRep) (a :: TYPE r) =
(# Maybe# (Leftovers# s), Either# (Maybe e) a, c #)
newtype ParserLevity e c (r :: RuntimeRep) (a :: TYPE r) = ParserLevity
{ getParserLevity :: forall s.
c
-> Maybe# (Leftovers# s)
-> State# s
-> (# State# s, Result# e c s r a #)
}
```
Specifically, the function causing trouble is (as currently defined):
```hs
{-# NOINLINE takeBytesUntilEndOfLineConsumeUnboxed #-}
takeBytesUntilEndOfLineConsumeUnboxed :: ParserLevity e c BytesRep Bytes#
takeBytesUntilEndOfLineConsumeUnboxed = ParserLevity (go (# (# #) | #)) where
go :: Maybe# Bytes# -> c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s BytesRep Bytes# #)
go !_ c (# (# #) | #) s0 = (# s0, (# (# (# #) | #), (# Nothing | #), c #) #)
go !mbytes c (# | (# bytes0@(# arr0, off0, len0 #), !stream0@(ByteStream streamFunc) #) #) s0 = case BAW.findAnyByte2 (I# off0) (I# len0) 10 13 (ByteArray arr0) of
Nothing -> case streamFunc s0 of
(# s1, r #) -> go (# | appendMaybeBytes mbytes bytes0 #) c r s1
Just (I# ix, W8# theByte) -> case theByte of
10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 1# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
-- second case means it was 13
_ -> case ix <# (off0 +# len0 -# 1#) of
1# -> case indexWord8Array# arr0 (ix +# 1# ) of
10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 2# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
_ -> (# s0, (# (# | (# unsafeDrop# (ix -# off0) bytes0, stream0 #) #), (# Nothing | #), c #) #)
_ -> case nextNonEmpty stream0 s0 of
(# s1, m #) -> case m of
(# (# #) | #) -> (# s1, (# (# | (# unboxBytes (B.singleton 13), Stream.empty #) #), (# Nothing | #), c #) #)
(# | (# bytes1@(# arr1, _, _ #), stream1 #) #) -> case indexWord8Array# arr1 0# of
10## -> (# s1, (# (# | (# unsafeDrop# 1# bytes1, stream1 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
_ -> (# s1, (# (# | (# unboxBytes (B.cons 13 (boxBytes bytes1)), stream1 #) #), (# Nothing | #), c #) #)
```
That's all I've got for now. If no one's able to make headway, I'll probably come back to this and try to make a more minimal example at some point. I won't have time to do this soon though.8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15301Regression in Natural desugaring2019-07-07T18:13:22ZSylvain HenryRegression in Natural desugaringMy recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadat...My recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression in Natural desugaring","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My recent merged patch \"Built-in Natural literals in Core\" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.\r\n\r\nPatch coming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15329Cannot parse `type (*)` in fixity declaration2019-07-07T18:13:08ZRichard Eisenbergrae@richarde.devCannot parse `type (*)` in fixity declarationVanessa McHale posts:
The parser seems to be broken. Attempting to build [basement](http://hackage.haskell.org/package/basement) yields:
```
Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+...Vanessa McHale posts:
The parser seems to be broken. Attempting to build [basement](http://hackage.haskell.org/package/basement) yields:
```
Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^
```
This is actually in 8.6.0, but there is no version option for this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot parse `type (*)` in fixity declaration","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Vanessa McHale posts:\r\n\r\nThe parser seems to be broken. Attempting to build [http://hackage.haskell.org/package/basement basement] yields:\r\n\r\n{{{\r\nBasement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^\r\n}}}\r\n\r\nThis is actually in 8.6.0, but there is no version option for this.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15390Figure out why CircleCI isn't generating haddocks2019-07-07T18:12:51ZBen GamariFigure out why CircleCI isn't generating haddocks<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Figure out why CircleCI isn't generating haddocks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15400Parse error on input ‘*’2019-07-07T18:05:05ZBodigrimParse error on input ‘*’Both GHC 8.6.1-alpha1 and 8.6.1-alpha2 fail to build `numtype-dk` package, while GHC 8.4.3 and HEAD work fine.
```
Configuring numtype-dk-0.5.0.1...
Preprocessing library for numtype-dk-0.5.0.1..
Building library for numtype-dk-0.5.0.1....Both GHC 8.6.1-alpha1 and 8.6.1-alpha2 fail to build `numtype-dk` package, while GHC 8.4.3 and HEAD work fine.
```
Configuring numtype-dk-0.5.0.1...
Preprocessing library for numtype-dk-0.5.0.1..
Building library for numtype-dk-0.5.0.1..
Numeric/NumType/DK/Integers.hs:38:29: error:
parse error on input ‘*’
|
38 | type (+), type (-), type (*), type (/), type (^),
|
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parse error on input ‘*’","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Both GHC 8.6.1-alpha1 and 8.6.1-alpha2 fail to build `numtype-dk` package, while GHC 8.4.3 and HEAD work fine.\r\n{{{\r\nConfiguring numtype-dk-0.5.0.1...\r\nPreprocessing library for numtype-dk-0.5.0.1..\r\nBuilding library for numtype-dk-0.5.0.1..\r\nNumeric/NumType/DK/Integers.hs:38:29: error:\r\n parse error on input ‘*’\r\n |\r\n38 | type (+), type (-), type (*), type (/), type (^),\r\n | \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15419GHC 8.6.1 regression (buildKindCoercion)2019-07-07T18:04:59ZRyan ScottGHC 8.6.1 regression (buildKindCoercion)The following program typechecks on GHC 8.4.1, but panics on GHC 8.6.1 and HEAD:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes ...The following program typechecks on GHC 8.4.1, but panics on GHC 8.6.1 and HEAD:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug where
import Data.Kind
data family Sing :: forall k. k -> Type
data TyFun :: Type -> Type -> Type
type a ~> b = TyFun a b -> Type
infixr 0 ~>
type family Apply (f :: k1 ~> k2) (x :: k1) :: k2
data instance Sing :: forall a b. (a, b) -> Type where
STuple2 :: Sing x -> Sing y -> Sing '(x, y)
newtype instance Sing (f :: k1 ~> k2) =
SLambda { applySing :: forall t. Sing t -> Sing (f `Apply` t) }
-----
newtype Par1 p = Par1 p
newtype K1 c p = K1 c
data (f :*: g) p = f p :*: g p
data instance Sing :: forall p. Par1 p -> Type where
SPar1 :: Sing x -> Sing ('Par1 x)
data instance Sing :: forall k c (p :: k). K1 c p -> Type where
SK1 :: Sing x -> Sing ('K1 x)
data instance Sing :: forall k (f :: k -> Type) (g :: k -> Type) (p :: k).
(f :*: g) p -> Type where
(:%*:) :: Sing x -> Sing y -> Sing (x ':*: y)
class Generic1 (f :: k -> Type) where
type Rep1 f :: k -> Type
from1 :: f a -> Rep1 f a
to1 :: Rep1 f a -> f a
class PGeneric1 (f :: k -> Type) where
type From1 (z :: f a) :: Rep1 f a
type To1 (z :: Rep1 f a) :: f a
class SGeneric1 (f :: k -> Type) where
sFrom1 :: forall (a :: k) (z :: f a). Sing z -> Sing (From1 z)
sTo1 :: forall (a :: k) (r :: Rep1 f a). Sing r -> Sing (To1 r :: f a)
instance Generic1 ((,) a) where
type Rep1 ((,) a) = K1 a :*: Par1
from1 (x, y) = K1 x :*: Par1 y
to1 (K1 x :*: Par1 y) = (x, y)
instance PGeneric1 ((,) a) where
type From1 '(x, y) = 'K1 x ':*: 'Par1 y
type To1 ('K1 x ':*: 'Par1 y) = '(x, y)
instance SGeneric1 ((,) a) where
sFrom1 (STuple2 x y) = SK1 x :%*: SPar1 y
sTo1 (SK1 x :%*: SPar1 y) = STuple2 x y
-----
type family GenericFmap (g :: a ~> b) (x :: f a) :: f b where
GenericFmap g x = To1 (Fmap g (From1 x))
class PFunctor (f :: Type -> Type) where
type Fmap (g :: a ~> b) (x :: f a) :: f b
type Fmap g x = GenericFmap g x
class SFunctor (f :: Type -> Type) where
sFmap :: forall a b (g :: a ~> b) (x :: f a).
Sing g -> Sing x -> Sing (Fmap g x)
default sFmap :: forall a b (g :: a ~> b) (x :: f a).
( SGeneric1 f, SFunctor (Rep1 f)
, Fmap g x ~ GenericFmap g x )
=> Sing g -> Sing x -> Sing (Fmap g x)
sFmap sg sx = sTo1 (sFmap sg (sFrom1 sx))
-----
instance PFunctor Par1 where
type Fmap f ('Par1 x) = 'Par1 (f `Apply` x)
instance PFunctor (K1 c) where
type Fmap _ ('K1 x) = 'K1 x
instance PFunctor (f :*: g) where
type Fmap h (x ':*: y) = Fmap h x ':*: Fmap h y
instance SFunctor Par1 where
sFmap sf (SPar1 sx) = SPar1 (sf `applySing` sx)
instance SFunctor (K1 c) where
sFmap _ (SK1 sx) = SK1 sx
instance (SFunctor f, SFunctor g) => SFunctor (f :*: g) where
sFmap sh (sx :%*: sy) = sFmap sh sx :%*: sFmap sh sy
-----
instance PFunctor ((,) a)
-- The line below causes the panic
instance SFunctor ((,) a)
```
```
$ /opt/ghc/8.6.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.0.20180714 for x86_64-unknown-linux):
buildKindCoercion
K1 a_a1Nj :*: Par1
Rep1 ((,) a_a1Nj)
*
a_a1Nj
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/types/Coercion.hs:2069:9 in ghc:Coercion
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.6.1 regression (buildKindCoercion)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program typechecks on GHC 8.4.1, but panics on GHC 8.6.1 and HEAD:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata family Sing :: forall k. k -> Type\r\ndata TyFun :: Type -> Type -> Type\r\ntype a ~> b = TyFun a b -> Type\r\ninfixr 0 ~>\r\ntype family Apply (f :: k1 ~> k2) (x :: k1) :: k2\r\n\r\ndata instance Sing :: forall a b. (a, b) -> Type where\r\n STuple2 :: Sing x -> Sing y -> Sing '(x, y)\r\nnewtype instance Sing (f :: k1 ~> k2) =\r\n SLambda { applySing :: forall t. Sing t -> Sing (f `Apply` t) }\r\n\r\n-----\r\n\r\nnewtype Par1 p = Par1 p\r\nnewtype K1 c p = K1 c\r\ndata (f :*: g) p = f p :*: g p\r\n\r\ndata instance Sing :: forall p. Par1 p -> Type where\r\n SPar1 :: Sing x -> Sing ('Par1 x)\r\ndata instance Sing :: forall k c (p :: k). K1 c p -> Type where\r\n SK1 :: Sing x -> Sing ('K1 x)\r\ndata instance Sing :: forall k (f :: k -> Type) (g :: k -> Type) (p :: k).\r\n (f :*: g) p -> Type where\r\n (:%*:) :: Sing x -> Sing y -> Sing (x ':*: y)\r\n\r\nclass Generic1 (f :: k -> Type) where\r\n type Rep1 f :: k -> Type\r\n from1 :: f a -> Rep1 f a\r\n to1 :: Rep1 f a -> f a\r\n\r\nclass PGeneric1 (f :: k -> Type) where\r\n type From1 (z :: f a) :: Rep1 f a\r\n type To1 (z :: Rep1 f a) :: f a\r\n\r\nclass SGeneric1 (f :: k -> Type) where\r\n sFrom1 :: forall (a :: k) (z :: f a). Sing z -> Sing (From1 z)\r\n sTo1 :: forall (a :: k) (r :: Rep1 f a). Sing r -> Sing (To1 r :: f a)\r\n\r\ninstance Generic1 ((,) a) where\r\n type Rep1 ((,) a) = K1 a :*: Par1\r\n from1 (x, y) = K1 x :*: Par1 y\r\n to1 (K1 x :*: Par1 y) = (x, y)\r\n\r\ninstance PGeneric1 ((,) a) where\r\n type From1 '(x, y) = 'K1 x ':*: 'Par1 y\r\n type To1 ('K1 x ':*: 'Par1 y) = '(x, y)\r\n\r\ninstance SGeneric1 ((,) a) where\r\n sFrom1 (STuple2 x y) = SK1 x :%*: SPar1 y\r\n sTo1 (SK1 x :%*: SPar1 y) = STuple2 x y\r\n\r\n-----\r\n\r\ntype family GenericFmap (g :: a ~> b) (x :: f a) :: f b where\r\n GenericFmap g x = To1 (Fmap g (From1 x))\r\n\r\nclass PFunctor (f :: Type -> Type) where\r\n type Fmap (g :: a ~> b) (x :: f a) :: f b\r\n type Fmap g x = GenericFmap g x\r\n\r\nclass SFunctor (f :: Type -> Type) where\r\n sFmap :: forall a b (g :: a ~> b) (x :: f a).\r\n Sing g -> Sing x -> Sing (Fmap g x)\r\n default sFmap :: forall a b (g :: a ~> b) (x :: f a).\r\n ( SGeneric1 f, SFunctor (Rep1 f)\r\n , Fmap g x ~ GenericFmap g x )\r\n => Sing g -> Sing x -> Sing (Fmap g x)\r\n sFmap sg sx = sTo1 (sFmap sg (sFrom1 sx))\r\n\r\n-----\r\n\r\ninstance PFunctor Par1 where\r\n type Fmap f ('Par1 x) = 'Par1 (f `Apply` x)\r\ninstance PFunctor (K1 c) where\r\n type Fmap _ ('K1 x) = 'K1 x\r\ninstance PFunctor (f :*: g) where\r\n type Fmap h (x ':*: y) = Fmap h x ':*: Fmap h y\r\n\r\ninstance SFunctor Par1 where\r\n sFmap sf (SPar1 sx) = SPar1 (sf `applySing` sx)\r\ninstance SFunctor (K1 c) where\r\n sFmap _ (SK1 sx) = SK1 sx\r\ninstance (SFunctor f, SFunctor g) => SFunctor (f :*: g) where\r\n sFmap sh (sx :%*: sy) = sFmap sh sx :%*: sFmap sh sy\r\n\r\n-----\r\n\r\ninstance PFunctor ((,) a)\r\n-- The line below causes the panic\r\ninstance SFunctor ((,) a)\r\n}}}\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.0.20180714 for x86_64-unknown-linux):\r\n buildKindCoercion\r\n K1 a_a1Nj :*: Par1\r\n Rep1 ((,) a_a1Nj)\r\n *\r\n a_a1Nj\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Coercion.hs:2069:9 in ghc:Coercion\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15430Merge llvm fix to ghc-8.62019-07-07T18:04:56ZKrzysztof GogolewskiMerge llvm fix to ghc-8.6This ticket is a reminder to make sure that https://phabricator.haskell.org/D4969 (Fix a major copy'n'paste error in LLVM CodeGen) is merged to ghc-8.6.
<details><summary>Trac metadata</summary>
| Trac field | Value ...This ticket is a reminder to make sure that https://phabricator.haskell.org/D4969 (Fix a major copy'n'paste error in LLVM CodeGen) is merged to ghc-8.6.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Merge llvm fix to ghc-8.6","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This ticket is a reminder to make sure that https://phabricator.haskell.org/D4969 (Fix a major copy'n'paste error in LLVM CodeGen) is merged to ghc-8.6.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15473GHC 8.6+ loops infinitely on an UndecidableInstances error message2019-07-07T18:04:35ZRyan ScottGHC 8.6+ loops infinitely on an UndecidableInstances error messageThis regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program:
``...This regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
-- {-# LANGUAGE UndecidableInstances #-}
module Bug where
type family Undefined :: k where {}
type family LetInterleave xs t ts is (a_ahkO :: [a]) (a_ahkP :: [[a]]) :: [[a]] where
LetInterleave xs t ts is y z = Undefined y z
```
You'll get this far:
```
$ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:3: error:
• Variables ‘a, a’ occur more often
in the type family application
```
Before GHC hangs. (I was unable to kill this with Ctrl+C; I had to resort to `kill -9`.)
Interestingly, the commit f8618a9b15177ee8c84771b927cb3583c9cd8408 (`Remove the type-checking knot.`) does not appear to have an effect on this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.6+ loops infinitely on an UndecidableInstances error message","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"This regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n-- {-# LANGUAGE UndecidableInstances #-}\r\nmodule Bug where\r\n\r\ntype family Undefined :: k where {}\r\n\r\ntype family LetInterleave xs t ts is (a_ahkO :: [a]) (a_ahkP :: [[a]]) :: [[a]] where\r\n LetInterleave xs t ts is y z = Undefined y z\r\n}}}\r\n\r\nYou'll get this far:\r\n\r\n{{{\r\n$ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:11:3: error:\r\n • Variables ‘a, a’ occur more often\r\n in the type family application\r\n}}}\r\n\r\nBefore GHC hangs. (I was unable to kill this with Ctrl+C; I had to resort to `kill -9`.)\r\n\r\nInterestingly, the commit f8618a9b15177ee8c84771b927cb3583c9cd8408 (`Remove the type-checking knot.`) does not appear to have an effect on this.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15475Plugin recompilation check still panics2019-07-07T18:04:34ZMatthew PickeringPlugin recompilation check still panicsI get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch.
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPlugin...I get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch.
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPluginUsage: file not found
LiftPlugin /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSlift-plugin-0.1.0.0-LpWZumtLigSEjndVxGCyUH-ghc8.6.1.20180803.so
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
My example is nixified and not very minimal but I can provide it tomorrow if that would help.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Plugin recompilation check still panics","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch. \r\n\r\n{{{\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.1.20180803 for x86_64-unknown-linux):\r\n\tmkPluginUsage: file not found\r\n LiftPlugin /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSlift-plugin-0.1.0.0-LpWZumtLigSEjndVxGCyUH-ghc8.6.1.20180803.so\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nMy example is nixified and not very minimal but I can provide it tomorrow if that would help.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15492Plugin recompilation check fails when profiling is enabled2019-07-07T18:04:30ZMatthew PickeringPlugin recompilation check fails when profiling is enabledWhen compiling with profiling enabled and using a plugin, GHC will panic as follows:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPluginUsage: no dylibs
GraphMod
Call...When compiling with profiling enabled and using a plugin, GHC will panic as follows:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPluginUsage: no dylibs
GraphMod
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage
```
Investigating determines that the following paths are being inspected:
```
/nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod-plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so
/nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so
/nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so
```
None of which exist.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Plugin recompilation check fails when profiling is enabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling with profiling enabled and using a plugin, GHC will panic as follows:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.1.20180803 for x86_64-unknown-linux):\r\n mkPluginUsage: no dylibs\r\n GraphMod\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage\r\n}}}\r\n\r\nInvestigating determines that the following paths are being inspected:\r\n\r\n{{{\r\n/nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod-plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so\r\n\r\n/nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so\r\n\r\n/nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so\r\n}}}\r\n\r\nNone of which exist.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15569Constant folding optimises 1 into 32019-07-07T18:04:05ZAndrey MokhovConstant folding optimises 1 into 3A recent Hadrian issue \[1\] led me to finding a rather embarrassing bug:
```hs
-- This is just subtraction in disguise
minus :: Int -> Int -> Int
minus x y = (8 - y) - (8 - x)
{-# NOINLINE minus #-}
main :: IO ()
main = print (2 `minu...A recent Hadrian issue \[1\] led me to finding a rather embarrassing bug:
```hs
-- This is just subtraction in disguise
minus :: Int -> Int -> Int
minus x y = (8 - y) - (8 - x)
{-# NOINLINE minus #-}
main :: IO ()
main = print (2 `minus` 1)
```
When compiled using `ghc-8.6.0.20180810` without optimisation this prints `1`, as expected, but when compiled with `-O` this prints `3`.
Here is the incorrect rewrite rule \[2\]:
```hs
(L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v)
```
This should be changed to:
```hs
(L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `sub` v)
```
Happy to submit the fix, but I'm not yet fully convinced that there are no other lurking bugs. This whole constant folding business is very error-prone.
\[1\] https://github.com/snowleopard/hadrian/issues/641
\[2\] https://github.com/ghc/ghc/blob/master/compiler/prelude/PrelRules.hs\#L17868.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15579topNormaliseType is wrong2019-07-07T18:04:02ZSimon Peyton JonestopNormaliseType is wrongI’m very puzzled about topNormaliseTYpe_maybe. Here it is:
```haskell
topNormaliseType_maybe env ty
= topNormaliseTypeX stepper mkTransCo ty
where
stepper = unwrapNewTypeStepper `composeSteppers` tyFamStepper
tyFamStepper r...I’m very puzzled about topNormaliseTYpe_maybe. Here it is:
```haskell
topNormaliseType_maybe env ty
= topNormaliseTypeX stepper mkTransCo ty
where
stepper = unwrapNewTypeStepper `composeSteppers` tyFamStepper
tyFamStepper rec_nts tc tys -- Try to step a type/data family
= let (args_co, ntys) = normaliseTcArgs env Representational tc tys in
-- NB: It's OK to use normaliseTcArgs here instead of
-- normalise_tc_args (which takes the LiftingContext described
-- in Note [Normalising types]) because the reduceTyFamApp below
-- works only at top level. We'll never recur in this function
-- after reducing the kind of a bound tyvar.
case reduceTyFamApp_maybe env Representational tc ntys of
Just (co, rhs) -> NS_Step rec_nts rhs (args_co `mkTransCo` co)
_ -> NS_Done
```
I have two puzzlements
1. First, it seems utterly wrong to normalise the arguments using Representational. Consider
```haskell
F (N Int)
where newtype N x = [x]
```
> We don’t want to reduce `(N Int)` to `[Int]`, and then try reducing `(F [Int])`!! That is totally bogus. Surely we should use (the role-aware) `normalise_tc_args` here?
1. I have literally no clue what `Note [Normalising types]` is all about. Moreover there is no Lifting Context passed to `normalise_tc_args`, so I don’t know what this stuff about `LiftingContext` is about. Is this historical baggage?
Richard and I discussed this. (1) is a bug; for (2) the comment is misleading and should be deleted.
Richard will do these things -- and will add examples to the mysterious `Note [Normalising types]`8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15623Wrong Endian, ghc-pwd and ghc-cabal on ghc 8.0.1 for powerpc64le (IBM Power)2019-07-07T18:03:42ZfrancescantoncastroWrong Endian, ghc-pwd and ghc-cabal on ghc 8.0.1 for powerpc64le (IBM Power)I tried to compile ghc-8.0.1 from source using the powerpc64/unknown linux .tar.xz file (since the other file was for AIX).
The ghc-pwd and ghc-cabal files won't execute even after stripping them with strip.
The libraries included are ...I tried to compile ghc-8.0.1 from source using the powerpc64/unknown linux .tar.xz file (since the other file was for AIX).
The ghc-pwd and ghc-cabal files won't execute even after stripping them with strip.
The libraries included are Big Endian instead of Little Endian.
I replaced the libffi library by the local one on my system (IBM Power8 with redhatenterpriseserver).
ghc complains there is no cabal file after naming a symlink to cabal (on /bin) ghc-cabal (instead of the faulty ghc-cabal file).
See attached file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Wrong Endian, ghc-pwd and ghc-cabal on ghc 8.0.1 for powerpc64le (IBM Power)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to compile ghc-8.0.1 from source using the powerpc64/unknown linux .tar.xz file (since the other file was for AIX).\r\n\r\nThe ghc-pwd and ghc-cabal files won't execute even after stripping them with strip.\r\n\r\nThe libraries included are Big Endian instead of Little Endian.\r\n\r\nI replaced the libffi library by the local one on my system (IBM Power8 with redhatenterpriseserver).\r\n\r\nghc complains there is no cabal file after naming a symlink to cabal (on /bin) ghc-cabal (instead of the faulty ghc-cabal file). \r\n\r\nSee attached file.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1