GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-11-24T17:43:44Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12076"lazy" leads to undefined reference to `stg_ap_0_upd_info'2023-11-24T17:43:44ZEdward Z. Yang"lazy" leads to undefined reference to `stg_ap_0_upd_info'This is basically the same thing as #11155 but triggered differently.
```
-- M.hs
{-# OPTIONS_GHC -O0 #-}
module M(f) where
import GHC.Exts
{-# NOINLINE z #-}
z = ()
f :: () -> ()
f _ = let x = lazy z
in g x x
{-# NOINLINE g #...This is basically the same thing as #11155 but triggered differently.
```
-- M.hs
{-# OPTIONS_GHC -O0 #-}
module M(f) where
import GHC.Exts
{-# NOINLINE z #-}
z = ()
f :: () -> ()
f _ = let x = lazy z
in g x x
{-# NOINLINE g #-}
g :: () -> () -> ()
g _ _ = ()
-- MM.hs
import M
main = f `seq` return ()
```
On GHC 8.0, I get:
```
ezyang@sabre:~$ ghc-8.0 --make MM.hs -fforce-recomp
[1 of 2] Compiling M ( M.hs, M.o )
[2 of 2] Compiling Main ( MM.hs, MM.o )
Linking MM ...
./M.o: In function `r2aD_info':
(.text+0x4a): undefined reference to `stg_ap_0_upd_info'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
```
Error goes away when you turn on optimization. My understanding is that removing `lazy` in `CorePrep` is too late, because there's no pass afterwards that eliminates the trivial thunk assignment. Here's the STG:
```
z_r2aC :: ()
[GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] =
NO_CCS ()! [];
g_r2aD :: () -> () -> ()
[GblId, Arity=2, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] =
sat-only \r srt:SRT:[] [ds_s2rW ds1_s2rX] () [];
M.f :: () -> ()
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] =
\r srt:SRT:[] [ds_s2rY]
let {
x_s2rZ :: ()
[LclId, Str=DmdType, Unf=OtherCon []] =
\u srt:SRT:[] [] z_r2aC;
} in g_r2aD x_s2rZ x_s2rZ;
```
so we need, instead, something like `x_s2rZ = z_r2aC`.
This is blocking [D2211](https://phabricator.haskell.org/D2211), where the insertion of a `noinline` (which is optimized out similarly to `lazy`) triggers a stage 2 linker failure when you don't compile with optimization (unfortunately, this is NOT caught validate since we build GHC with optimization... but with this test it will be!)
Perhaps there should be an ASSERT in the codegen so it doesn't create this symbol?8.0.2Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/12939ghc-8.0.1.20161117 did not install ghc.1 manpage2023-07-23T05:03:57ZJens Petersenghc-8.0.1.20161117 did not install ghc.1 manpageThis seems to be a build regression from ghc-8.0.1.
The ghc.1 manpage was not installed for the 8.0.2 RC1 build.
I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstrea...This seems to be a build regression from ghc-8.0.1.
The ghc.1 manpage was not installed for the 8.0.2 RC1 build.
I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2-rc1 |
| 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":"ghc-8.0.1.20161117 did not install ghc.1 manpage","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This seems to be a build regression from ghc-8.0.1.\r\n\r\nThe ghc.1 manpage was not installed for the 8.0.2 RC1 build.\r\n\r\nI reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12759Latest Debian GCC breaks GHC2023-07-17T18:00:28ZerikdLatest Debian GCC breaks GHCJust got `gcc (Debian 6.2.0-9) 6.2.0 20161019` in a recent upgrade (Debian Testing) and now:
```
> cat hello.hs
main :: IO ()
main = putStrLn "Hello"
> ghc hello.hs -o hello
[1 of 1] Compiling Main ( hello.hs, hello.o )
Li...Just got `gcc (Debian 6.2.0-9) 6.2.0 20161019` in a recent upgrade (Debian Testing) and now:
```
> cat hello.hs
main :: IO ()
main = putStrLn "Hello"
> ghc hello.hs -o hello
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...
/usr/bin/ld: hello.o: relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' \
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/ghc-8.0/lib/base-4.9.0.0/libHSbase-4.9.0.0.a(Base__166.o): \
relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when \
making a shared object; recompile with -fPIC
....
```
The previous version of gcc in Debian Testing (gcc (Debian 6.2.0-6) 6.2.0 20161010) is fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Latest Debian GCC breajs GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just got `gcc (Debian 6.2.0-9) 6.2.0 20161019` in a recent upgrade (Debian Testing) and now:\r\n{{{\r\n> cat hello.hs \r\nmain :: IO ()\r\nmain = putStrLn \"Hello\"\r\n\r\n> ghc hello.hs -o hello\r\n[1 of 1] Compiling Main ( hello.hs, hello.o )\r\nLinking hello ...\r\n/usr/bin/ld: hello.o: relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' \\\r\ncan not be used when making a shared object; recompile with -fPIC\r\n/usr/bin/ld: /usr/lib/ghc-8.0/lib/base-4.9.0.0/libHSbase-4.9.0.0.a(Base__166.o): \\\r\nrelocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when \\\r\nmaking a shared object; recompile with -fPIC\r\n....\r\n}}}\r\n\r\nThe previous version of gcc in Debian Testing (gcc (Debian 6.2.0-6) 6.2.0 20161010) is fine.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12466Typechecker regression: Inaccessible code in a type expected by the context2023-05-18T09:20:00ZRyan ScottTypechecker regression: Inaccessible code in a type expected by the contextThe following compiles with GHC 8.0.1 and earlier, but not with GHC HEAD:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
class Foo a where
foo :: (a ~ Int => Int) -> a -> a
foo _ a2 = a2
instance ...The following compiles with GHC 8.0.1 and earlier, but not with GHC HEAD:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
class Foo a where
foo :: (a ~ Int => Int) -> a -> a
foo _ a2 = a2
instance Foo Char
```
```
$ /opt/ghc/head/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:9:10: error:
• Couldn't match type ‘Char’ with ‘Int’
Inaccessible code in
a type expected by the context:
Char ~ Int => Int
• In the expression: Bug.$dmfoo @Char
In an equation for ‘foo’: foo = Bug.$dmfoo @Char
In the instance declaration for ‘Foo Char’
```
This causes `lens-4.14` to [fail to build](https://github.com/ekmett/lens/issues/667) with GHC HEAD.
The reason HEAD fails to compile `lens`, but GHC 8.0.1 works, is because the fix for #12220 is in HEAD, but not in 8.0.1.8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12757Compiled program segfaults at -O12023-04-19T09:06:43ZHerbert Valerio Riedelhvr@gnu.orgCompiled program segfaults at -O1This affects GHC 8.0.2dev (d84a824cebe94711528727bcb587bfc369ec36a2) as well as GHC HEAD (c23dc6164d54eacc654516b885104dc8b7678f16)
The following program results in a segfault when compiled at -O1 or more:
```hs
{-# LANGUAGE Overloaded...This affects GHC 8.0.2dev (d84a824cebe94711528727bcb587bfc369ec36a2) as well as GHC HEAD (c23dc6164d54eacc654516b885104dc8b7678f16)
The following program results in a segfault when compiled at -O1 or more:
```hs
{-# LANGUAGE OverloadedStrings #-}
module Main (main) where
import Data.ByteString (ByteString)
import qualified Data.ByteString as B
answers :: [ByteString]
answers = map (B.filter (/= 0x20))
[ "e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855"
, "d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592"
, "e4c4d8f3 bf76b692 de791a17 3e053211 50f7a345 b46484fe 427f6acc 7ecc81be"
, "ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad"
, "248d6a61 d20638b8 e5c02693 0c3e6039 a33ce459 64ff2167 f6ecedd4 19db06c1"
, "cf5b16a7 78af8380 036ce59e 7b049237 0b249b11 e8f07a51 afac4503 7afee9d1"
, "cdc76e5c 9914fb92 81a1c7e2 84d73e67 f1809a48 a497200e 046d39cc c7112cd0"
]
x, y :: ByteString
x = "e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855"
y = B.filter (/= 0x20) x
main :: IO ()
main = do
print (seq x ())
print (seq y ())
print (length answers)
print (seq (head answers) ()) -- segfault!
```
```
$ ghc-8.0.2 -fforce-recomp --make -O1 bug.hs && ./bug
[1 of 1] Compiling Main ( bug.hs, bug.o )
Linking bug ...
()
()
7
Segmentation fault
```
```
$ ghc-8.0.2 -fforce-recomp --make -O0 bug.hs && ./bug
[1 of 1] Compiling Main ( bug.hs, bug.o )
Linking bug ...
()
()
7
()
```
I haven't yet investigated why this happens.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Compiled program segfaults at -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This affects GHC 8.0.2dev (d84a824cebe94711528727bcb587bfc369ec36a2) as well as GHC HEAD (c23dc6164d54eacc654516b885104dc8b7678f16)\r\n\r\nThe following program results in a segfault when compiled at -O1 or more:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE OverloadedStrings #-}\r\n\r\nmodule Main (main) where\r\n\r\nimport Data.ByteString (ByteString)\r\nimport qualified Data.ByteString as B\r\n\r\nanswers :: [ByteString]\r\nanswers = map (B.filter (/= 0x20))\r\n [ \"e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855\"\r\n , \"d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592\"\r\n , \"e4c4d8f3 bf76b692 de791a17 3e053211 50f7a345 b46484fe 427f6acc 7ecc81be\"\r\n , \"ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad\"\r\n , \"248d6a61 d20638b8 e5c02693 0c3e6039 a33ce459 64ff2167 f6ecedd4 19db06c1\"\r\n , \"cf5b16a7 78af8380 036ce59e 7b049237 0b249b11 e8f07a51 afac4503 7afee9d1\"\r\n , \"cdc76e5c 9914fb92 81a1c7e2 84d73e67 f1809a48 a497200e 046d39cc c7112cd0\"\r\n ]\r\n\r\nx, y :: ByteString\r\nx = \"e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855\"\r\ny = B.filter (/= 0x20) x\r\n\r\nmain :: IO ()\r\nmain = do\r\n print (seq x ())\r\n print (seq y ())\r\n print (length answers)\r\n print (seq (head answers) ()) -- segfault!\r\n}}}\r\n\r\n\r\n{{{\r\n$ ghc-8.0.2 -fforce-recomp --make -O1 bug.hs && ./bug \r\n[1 of 1] Compiling Main ( bug.hs, bug.o )\r\nLinking bug ...\r\n()\r\n()\r\n7\r\nSegmentation fault\r\n}}}\r\n\r\n{{{\r\n$ ghc-8.0.2 -fforce-recomp --make -O0 bug.hs && ./bug \r\n[1 of 1] Compiling Main ( bug.hs, bug.o )\r\nLinking bug ...\r\n()\r\n()\r\n7\r\n()\r\n}}}\r\n\r\nI haven't yet investigated why this happens.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12858clock_gettime support on OS X is a nightmare2023-02-08T13:45:05ZBen Gamariclock_gettime support on OS X is a nightmareDarwin did not support `clock_gettime` until Sierra, which added it. Unfortunately, the existing `MACOSX_DEPLOYMENT_TARGET` environment variable has no effect on its availability, so binary distributions compiled on Sierra will be incomp...Darwin did not support `clock_gettime` until Sierra, which added it. Unfortunately, the existing `MACOSX_DEPLOYMENT_TARGET` environment variable has no effect on its availability, so binary distributions compiled on Sierra will be incompatible with older releases.
We have three options for dealing with this,
1. Disable `clock_gettime` support in our OS X binary distributions (e.g. `./configure ac_cv_func_clock_gettime=no`)
1. Produce one binary distribution for Sierra and another for previous releases
1. Making it possible to change timer backends at runtime.
At the moment I'm leaning towards (1). (2) is another possibility. (3) seems like a road to madness.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"clock_gettime support on OS X is a nightmare","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Darwin did not support `clock_gettime` until Sierra, which added it. Unfortunately, the existing `MACOSX_DEPLOYMENT_TARGET` environment variable has no effect on its availability, so binary distributions compiled on Sierra will be incompatible with older releases.\r\n\r\nWe have three options for dealing with this,\r\n1. Disable `clock_gettime` support in our OS X binary distributions (e.g. `./configure ac_cv_func_clock_gettime=no`)\r\n2. Produce one binary distribution for Sierra and another for previous releases\r\n3. Making it possible to change timer backends at runtime.\r\n\r\nAt the moment I'm leaning towards (1). (2) is another possibility. (3) seems like a road to madness.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12497Make runtime linker be able to find POSIX functions under their deprecated name.2022-12-05T23:36:35ZTamar ChristinaMake runtime linker be able to find POSIX functions under their deprecated name.With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN.
Unfortunately there seems to be far more libraries than expected using these deprecated names. ...With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN.
Unfortunately there seems to be far more libraries than expected using these deprecated names. (Rather, far more libraries using posix functions and it happening to work on Windows).
These are all broken now, and while we're doing the right thing, for the sake of compatibility with mingw-w64's behavior and allowing all these packages to work then we should re-export these symbols.
e.g. rexport `strdup` as a forward from `_strdup`. We don't have to actually re-export them. just forward them in `RtsSymbol.c`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make runtime linker be able to find POSIX functions under their deprecated name.","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN.\r\n\r\nUnfortunately there seems to be far more libraries than expected using these deprecated names. (Rather, far more libraries using posix functions and it happening to work on Windows). \r\n\r\nThese are all broken now, and while we're doing the right thing, for the sake of compatibility with mingw-w64's behavior and allowing all these packages to work then we should re-export these symbols.\r\n\r\ne.g. rexport `strdup` as a forward from `_strdup`. We don't have to actually re-export them. just forward them in `RtsSymbol.c`. ","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12433GHCi produces incorrect results when evaluating with compiled code2022-08-05T10:27:28ZIavor S. DiatchkiGHCi produces incorrect results when evaluating with compiled codeWhen GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:
```hs
import Lex
num = 100000
txt1 = "aaa,aaa"
main :: IO (...When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:
```hs
import Lex
num = 100000
txt1 = "aaa,aaa"
main :: IO ()
main = print $ sum $ map (length . haskellLex) $ replicate num txt1
```
This program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time.
To reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations:
```
ghc -c -O1 -dynamic Lex.hs
```
The source code for the "lexer" is as follows:
```haskell
module Lex (haskellLex) where
cclass :: Char -> Int
cclass c =
case c of
'a' -> 10
',' -> 11
'A' -> 0
'B' -> 0
'C' -> 0
'D' -> 0
'E' -> 0
'F' -> 0
haskellLex :: String -> [()]
haskellLex [] = []
haskellLex (i:is) =
case cclass i of
10 -> haskellLex62 is
11 -> () : haskellLex is
haskellLex62 :: String -> [()]
haskellLex62 [] = [()]
haskellLex62 (i:is) =
case cclass i of
0 -> [()]
1 -> [()]
2 -> [()]
3 -> [()]
4 -> [()]
10 -> haskellLex62 is
11 -> () : haskellLex (i:is)
x -> error ("[GHC BUG] cclass returned: " ++ show (i,x)
```
This is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program:
```
runhaskell test.hs
test.hs: [GHC BUG] cclass returned: (',',-556)
CallStack (from HasCallStack):
error, called at Lex.hs:36:12 in main:Lex
```
The problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`.
I've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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 produces incorrect results when evaluating with compiled code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["code","compiled","dynamic","ghci,","linking,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:\r\n{{{#!hs\r\nimport Lex\r\n\r\nnum = 100000\r\ntxt1 = \"aaa,aaa\"\r\n\r\nmain :: IO ()\r\nmain = print $ sum $ map (length . haskellLex) $ replicate num txt1\r\n}}}\r\n\r\nThis program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time.\r\n\r\nTo reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations:\r\n{{{\r\nghc -c -O1 -dynamic Lex.hs\r\n}}}\r\n\r\nThe source code for the \"lexer\" is as follows:\r\n{{{#!haskell\r\nmodule Lex (haskellLex) where\r\n\r\ncclass :: Char -> Int\r\ncclass c =\r\n case c of\r\n 'a' -> 10\r\n ',' -> 11\r\n\r\n 'A' -> 0\r\n 'B' -> 0\r\n 'C' -> 0\r\n 'D' -> 0\r\n 'E' -> 0\r\n 'F' -> 0\r\n\r\nhaskellLex :: String -> [()]\r\nhaskellLex [] = []\r\nhaskellLex (i:is) =\r\n case cclass i of\r\n 10 -> haskellLex62 is\r\n 11 -> () : haskellLex is\r\n\r\nhaskellLex62 :: String -> [()]\r\nhaskellLex62 [] = [()]\r\nhaskellLex62 (i:is) =\r\n case cclass i of\r\n 0 -> [()]\r\n 1 -> [()]\r\n 2 -> [()]\r\n 3 -> [()]\r\n 4 -> [()]\r\n\r\n 10 -> haskellLex62 is\r\n 11 -> () : haskellLex (i:is)\r\n\r\n x -> error (\"[GHC BUG] cclass returned: \" ++ show (i,x)\r\n}}}\r\n\r\nThis is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program:\r\n{{{\r\nrunhaskell test.hs\r\ntest.hs: [GHC BUG] cclass returned: (',',-556)\r\nCallStack (from HasCallStack):\r\n error, called at Lex.hs:36:12 in main:Lex\r\n}}}\r\n\r\nThe problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`.\r\n\r\nI've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/12562GHC panic on rebuild (idInfo r_XsTP)2021-05-25T17:17:59ZMoritz KieferGHC panic on rebuild (idInfo r_XsTP)### Steps to reproduce
```
git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic
cd llvm-general
cabal new-build llvm-general
curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2...### Steps to reproduce
```
git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic
cd llvm-general
cabal new-build llvm-general
curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2b70a8cc1a1aed7a44b418fba04e8df4818c1237/out.patch > out.patch
git apply out.patch
cabal new-build llvm-general
```
The patch just adds a newline somewhere to create a rebuild. I’ve seen this panic for completely different changes (all in this project) so I don’t think the change matters. I’ve also seen this panic with stack, cabal new-build and cabal build (using sandboxes).
### Output
```
In order, the following will be built (use -v for more details):
llvm-general-3.8.0.0
Preprocessing library llvm-general-3.8.0.0...
[84 of 92] Compiling LLVM.General.Internal.Module ( src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o )
[85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Module.o ) [LLVM.General.Internal.Module changed]
[89 of 92] Compiling LLVM.General.Internal.PassManager ( src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH]
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
idInfo r_XsTP
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
### Comments
In this case this can be resolved by running cabal new-build again. However I’ve also had cases where this didn’t fix it and I had to blow away dist-newstyle. I haven’t yet managed to find a reproducible testcase for the latter. Matthew Pickering mentioned that he encountered this (or a similar) bug while building GHC. I tried core-lint but that didn’t help.8.0.2Moritz KieferMoritz Kieferhttps://gitlab.haskell.org/ghc/ghc/-/issues/12124Ambiguous type variable: it's a red herring!2021-01-17T14:48:26ZDan BurtonAmbiguous type variable: it's a red herring!```
module Ret where
data Whoops = Whoops Int Int
foo :: Maybe Int
foo = return (case Whoops 1 2 of
Whoops a -> a
_ -> 0)
```
Note that there is a pattern match error in the case statement, which the compiler correctly reports. Ho...```
module Ret where
data Whoops = Whoops Int Int
foo :: Maybe Int
foo = return (case Whoops 1 2 of
Whoops a -> a
_ -> 0)
```
Note that there is a pattern match error in the case statement, which the compiler correctly reports. However, it first reports the following red herring:
```
ret.hs:6:7: error:
• Ambiguous type variable ‘m0’ arising from a use of ‘return’
prevents the constraint ‘(Monad m0)’ from being solved.
Probable fix: use a type annotation to specify what ‘m0’ should be.
These potential instances exist:
instance Monad IO -- Defined in ‘GHC.Base’
instance Monad Maybe -- Defined in ‘GHC.Base’
instance Monad ((->) r) -- Defined in ‘GHC.Base’
...plus two others
(use -fprint-potential-instances to see them all)
• In the expression:
return
(case Whoops 1 2 of {
Whoops a -> a
_ -> 0 })
In an equation for ‘foo’:
foo
= return
(case Whoops 1 2 of {
Whoops a -> a
_ -> 0 })
```
One would think that the context `foo :: Maybe Int` is sufficient for the compiler to realize that `return (blah)` implies that m0 = Maybe, regardless of the errors involved in the expression `(blah)`.
ghc 7.10.3 does not report this red herring. One can get a similar red-herring type error in ghc 7.10.3 by replacing `return (...)` with `return $ ...` in the example above.
The red herring also does \*not\* appear, in ghc 7.10.3 or in ghc 8.0.1, if you name the broken case expression with a let binding.
```
module Ret where
data Whoops = Whoops Int Int
foo :: Maybe Int
foo = return boo where
boo = case Whoops 1 2 of
Whoops a -> a
_ -> 0
```
There seems to be something fishy going on here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Ambiguous type variable: it's a red herring!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nmodule Ret where\r\n\r\ndata Whoops = Whoops Int Int\r\n\r\nfoo :: Maybe Int\r\nfoo = return (case Whoops 1 2 of\r\n Whoops a -> a\r\n _ -> 0)\r\n}}}\r\n\r\nNote that there is a pattern match error in the case statement, which the compiler correctly reports. However, it first reports the following red herring:\r\n\r\n{{{\r\nret.hs:6:7: error:\r\n • Ambiguous type variable ‘m0’ arising from a use of ‘return’\r\n prevents the constraint ‘(Monad m0)’ from being solved.\r\n Probable fix: use a type annotation to specify what ‘m0’ should be.\r\n These potential instances exist:\r\n instance Monad IO -- Defined in ‘GHC.Base’\r\n instance Monad Maybe -- Defined in ‘GHC.Base’\r\n instance Monad ((->) r) -- Defined in ‘GHC.Base’\r\n ...plus two others\r\n (use -fprint-potential-instances to see them all)\r\n • In the expression:\r\n return\r\n (case Whoops 1 2 of {\r\n Whoops a -> a\r\n _ -> 0 })\r\n In an equation for ‘foo’:\r\n foo\r\n = return\r\n (case Whoops 1 2 of {\r\n Whoops a -> a\r\n _ -> 0 })\r\n}}}\r\n\r\nOne would think that the context `foo :: Maybe Int` is sufficient for the compiler to realize that `return (blah)` implies that m0 = Maybe, regardless of the errors involved in the expression `(blah)`.\r\n\r\nghc 7.10.3 does not report this red herring. One can get a similar red-herring type error in ghc 7.10.3 by replacing `return (...)` with `return $ ...` in the example above.\r\n\r\nThe red herring also does *not* appear, in ghc 7.10.3 or in ghc 8.0.1, if you name the broken case expression with a let binding.\r\n\r\n{{{\r\nmodule Ret where\r\n\r\ndata Whoops = Whoops Int Int\r\n\r\nfoo :: Maybe Int\r\nfoo = return boo where\r\n boo = case Whoops 1 2 of\r\n Whoops a -> a\r\n _ -> 0\r\n}}}\r\n\r\nThere seems to be something fishy going on here.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12492internal error: allocation of 1048608 bytes too large2020-11-11T12:32:32Zerikdinternal error: allocation of 1048608 bytes too largeI'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is:
```
load-test: internal error: allocation of 1048608 bytes too large (GHC
sh...I'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is:
```
load-test: internal error: allocation of 1048608 bytes too large (GHC
should have complained at compile-time)
(GHC version 8.0.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
However, this message is bogus because this is not a static data structure known at compile time, but data loaded from disk. Currently, my test program just loads this complex data structure (about 27 megabytes of CSV with embedded JSON on disk) into memory and then calls `recursiveSize` from `GHC.Datasize` on it. I get this same error message with both ghc7.10.3 and ghc-8.0.1.
If I remove the call to `recursiveSize` there is no error.
If I `Control.Deepseq.force` the data structures before calling `recursiveSize` there is no error.
So, who is to blame? `ghc-datasize` is just Haskell code that calls public APIs so I think the blame lies with GHC.
I'll work on getting a small re-producable test case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"internal error: allocation of 1048608 bytes too large","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is:\r\n\r\n{{{\r\nload-test: internal error: allocation of 1048608 bytes too large (GHC\r\nshould have complained at compile-time)\r\n (GHC version 8.0.1 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nHowever, this message is bogus because this is not a static data structure known at compile time, but data loaded from disk. Currently, my test program just loads this complex data structure (about 27 megabytes of CSV with embedded JSON on disk) into memory and then calls `recursiveSize` from `GHC.Datasize` on it. I get this same error message with both ghc7.10.3 and ghc-8.0.1.\r\n\r\nIf I remove the call to `recursiveSize` there is no error.\r\n\r\nIf I `Control.Deepseq.force` the data structures before calling `recursiveSize` there is no error.\r\n\r\nSo, who is to blame? `ghc-datasize` is just Haskell code that calls public APIs so I think the blame lies with GHC.\r\n\r\nI'll work on getting a small re-producable test case.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/127688.0.2 derives invalid code when class method is constrained by itself2020-05-06T14:27:41Zjophish8.0.2 derives invalid code when class method is constrained by itselfGHC 8.0.1 is able to compile this without a problem and doesn't require FlexibleContexts.
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE ConstrainedClassMethods #-}
module A where
clas...GHC 8.0.1 is able to compile this without a problem and doesn't require FlexibleContexts.
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE ConstrainedClassMethods #-}
module A where
class C m where
foo :: C m => m ()
newtype N m a = N (m a)
deriving C
```
Compare the output of 8.0.1, 8.0.2 and 8.1. I turned on -fdefer-type-errors in order for -ddump-deriv to work.
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1
$ ghc -ddump-deriv A.hs
[1 of 1] Compiling A ( A.hs, A.o )
==================== Derived instances ====================
Derived instances:
instance A.C m_aNK => A.C (A.N m_aNK) where
A.foo = GHC.Prim.coerce (A.foo :: m_ap1 ()) :: A.N m_ap1 ()
GHC.Generics representation types:
```
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.2
$ ghc A.hs
[1 of 1] Compiling A ( A.hs, A.o )
A.hs:10:12: error:
• Couldn't match type ‘m’ with ‘N m’
arising from the coercion of the method ‘foo’
from type ‘C m => m ()’ to type ‘C (N m) => N m ()’
‘m’ is a rigid type variable bound by
the deriving clause for ‘C (N m)’ at A.hs:10:12
• When deriving the instance for (C (N m))
$ ghc -ddump-deriv -fdefer-type-errors A.hs
[1 of 1] Compiling A ( A.hs, A.o )
==================== Derived instances ====================
Derived instances:
instance A.C m_awm => A.C (A.N m_awm) where
A.foo
= GHC.Prim.coerce
@(A.C m_ap0 => m_ap0 ()) @(A.C (A.N m_ap0) => A.N m_ap0 ()) A.foo
GHC.Generics representation types:
A.hs:11:12: warning: [-Wdeferred-type-errors]
• Couldn't match type ‘m’ with ‘N m’
arising from a use of ‘GHC.Prim.coerce’
‘m’ is a rigid type variable bound by
the instance declaration at A.hs:11:12
• In the expression:
GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo
In an equation for ‘foo’:
foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo
When typechecking the code for ‘foo’
in a derived instance for ‘C (N m)’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‘C (N m)’
• Relevant bindings include foo :: N m () (bound at A.hs:11:12)
```
There's no '8.0.2' version to report this against so I've chosen 8.1. GHC 8.1 gives very similar results:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.1.20160930
$ ghc A.hs
[1 of 1] Compiling A ( A.hs, A.o )
A.hs:11:12: error:
• Couldn't match type ‘m’ with ‘N m’
arising from the coercion of the method ‘foo’
from type ‘C m => m ()’ to type ‘C (N m) => N m ()’
‘m’ is a rigid type variable bound by
the deriving clause for ‘C (N m)’ at A.hs:11:12
• When deriving the instance for (C (N m))
$ ghc -ddump-deriv -fdefer-type-errors A.hs
[1 of 1] Compiling A ( A.hs, A.o )
==================== Derived instances ====================
Derived instances:
instance A.C m_awK => A.C (A.N m_awK) where
A.foo
= GHC.Prim.coerce
@(A.C m_app => m_app ()) @(A.C (A.N m_app) => A.N m_app ()) A.foo
GHC.Generics representation types:
A.hs:11:12: warning: [-Wsimplifiable-class-constraints]
The constraint ‘C (N m)’ matches an instance declaration
instance C m => C (N m) -- Defined at A.hs:11:12
This makes type inference for inner bindings fragile;
either use MonoLocalBinds, or simplify it using the instance
A.hs:11:12: warning: [-Wdeferred-type-errors]
• Couldn't match type ‘m’ with ‘N m’
arising from a use of ‘GHC.Prim.coerce’
‘m’ is a rigid type variable bound by
the instance declaration at A.hs:11:12
• In the expression:
GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo
In an equation for ‘foo’:
foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo
When typechecking the code for ‘foo’
in a derived instance for ‘C (N m)’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‘C (N m)’
• Relevant bindings include foo :: N m () (bound at A.hs:11:12)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"8.0.2 derives invalid code when class method is constrained by itself","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 8.0.1 is able to compile this without a problem and doesn't require FlexibleContexts.\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE ConstrainedClassMethods #-}\r\n\r\nmodule A where\r\n\r\nclass C m where\r\n foo :: C m => m ()\r\n\r\nnewtype N m a = N (m a)\r\n deriving C\r\n}}}\r\n\r\nCompare the output of 8.0.1, 8.0.2 and 8.1. I turned on -fdefer-type-errors in order for -ddump-deriv to work.\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.0.1\r\n\r\n$ ghc -ddump-deriv A.hs\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n\r\n==================== Derived instances ====================\r\nDerived instances:\r\n instance A.C m_aNK => A.C (A.N m_aNK) where\r\n A.foo = GHC.Prim.coerce (A.foo :: m_ap1 ()) :: A.N m_ap1 ()\r\n\r\n\r\nGHC.Generics representation types:\r\n}}}\r\n\r\n{{{\r\n\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.0.2\r\n\r\n$ ghc A.hs\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n\r\nA.hs:10:12: error:\r\n • Couldn't match type ‘m’ with ‘N m’\r\n arising from the coercion of the method ‘foo’\r\n from type ‘C m => m ()’ to type ‘C (N m) => N m ()’\r\n ‘m’ is a rigid type variable bound by\r\n the deriving clause for ‘C (N m)’ at A.hs:10:12\r\n • When deriving the instance for (C (N m))\r\n\r\n$ ghc -ddump-deriv -fdefer-type-errors A.hs\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n\r\n==================== Derived instances ====================\r\nDerived instances:\r\n instance A.C m_awm => A.C (A.N m_awm) where\r\n A.foo\r\n = GHC.Prim.coerce\r\n @(A.C m_ap0 => m_ap0 ()) @(A.C (A.N m_ap0) => A.N m_ap0 ()) A.foo\r\n\r\n\r\nGHC.Generics representation types:\r\n\r\n\r\n\r\nA.hs:11:12: warning: [-Wdeferred-type-errors]\r\n • Couldn't match type ‘m’ with ‘N m’\r\n arising from a use of ‘GHC.Prim.coerce’\r\n ‘m’ is a rigid type variable bound by\r\n the instance declaration at A.hs:11:12\r\n • In the expression:\r\n GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo\r\n In an equation for ‘foo’:\r\n foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo\r\n When typechecking the code for ‘foo’\r\n in a derived instance for ‘C (N m)’:\r\n To see the code I am typechecking, use -ddump-deriv\r\n In the instance declaration for ‘C (N m)’\r\n • Relevant bindings include foo :: N m () (bound at A.hs:11:12)\r\n}}}\r\n\r\nThere's no '8.0.2' version to report this against so I've chosen 8.1. GHC 8.1 gives very similar results:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.1.20160930\r\n\r\n$ ghc A.hs\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n\r\nA.hs:11:12: error:\r\n • Couldn't match type ‘m’ with ‘N m’\r\n arising from the coercion of the method ‘foo’\r\n from type ‘C m => m ()’ to type ‘C (N m) => N m ()’\r\n ‘m’ is a rigid type variable bound by\r\n the deriving clause for ‘C (N m)’ at A.hs:11:12\r\n • When deriving the instance for (C (N m))\r\n\r\n$ ghc -ddump-deriv -fdefer-type-errors A.hs\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n\r\n==================== Derived instances ====================\r\nDerived instances:\r\n instance A.C m_awK => A.C (A.N m_awK) where\r\n A.foo\r\n = GHC.Prim.coerce\r\n @(A.C m_app => m_app ()) @(A.C (A.N m_app) => A.N m_app ()) A.foo\r\n\r\n\r\nGHC.Generics representation types:\r\n\r\n\r\n\r\nA.hs:11:12: warning: [-Wsimplifiable-class-constraints]\r\n The constraint ‘C (N m)’ matches an instance declaration\r\n instance C m => C (N m) -- Defined at A.hs:11:12\r\n This makes type inference for inner bindings fragile;\r\n either use MonoLocalBinds, or simplify it using the instance\r\n\r\nA.hs:11:12: warning: [-Wdeferred-type-errors]\r\n • Couldn't match type ‘m’ with ‘N m’\r\n arising from a use of ‘GHC.Prim.coerce’\r\n ‘m’ is a rigid type variable bound by\r\n the instance declaration at A.hs:11:12\r\n • In the expression:\r\n GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo\r\n In an equation for ‘foo’:\r\n foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo\r\n When typechecking the code for ‘foo’\r\n in a derived instance for ‘C (N m)’:\r\n To see the code I am typechecking, use -ddump-deriv\r\n In the instance declaration for ‘C (N m)’\r\n • Relevant bindings include foo :: N m () (bound at A.hs:11:12)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12095GHC and LLVM don't agree on what to do with byteSwap16#2020-01-06T17:32:27ZthoughtpoliceGHC and LLVM don't agree on what to do with byteSwap16#Consider this test case (taken from [here](https://github.com/well-typed/binary-serialise-cbor/issues/67) and lightly modified to work on big/little endian machines):
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE MagicHash #-}
{-#...Consider this test case (taken from [here](https://github.com/well-typed/binary-serialise-cbor/issues/67) and lightly modified to work on big/little endian machines):
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE CPP #-}
module Main
( main -- :: IO ()
) where
#include "ghcconfig.h"
import GHC.Prim
import GHC.Word
data T = T !Addr#
t :: T
#ifndef WORDS_BIGENDIAN
t = T "\xcf\xb1"#
#else
t = T "\xb1\xcf"#
#endif
grabWord16 :: T -> Word64
grabWord16 (T addr#) = W64# (byteSwap16# (indexWord16OffAddr# addr# 0#))
trip :: Int
trip = fromIntegral (grabWord16 t)
main :: IO ()
main = print trip
```
With GHC 7.10.3 using the NCG, the results given are correct:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
$ ghc -Wall -fforce-recomp -O2 Issue67.hs && ./Issue67
[1 of 1] Compiling Main ( Issue67.hs, Issue67.o )
Linking Issue67 ...
53169
```
This also is the same on GHC 8.0.1 using the NCG, on both PowerPC and AMD64 as well. This answer is correct: `53169` is `0xCFB1` in hex, so the `byteSwap16#` primitive correctly works to decode the swapped-endian number.
However, the story is not the same with GHC 7.10.3+LLVM 3.5, or GHC 8.0.1+LLVM 3.7:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
$ llc --version | head -2
LLVM (http://llvm.org/):
LLVM version 3.5.2
$ ghc -Wall -fforce-recomp -O2 Issue67.hs -fllvm && ./Issue67
[1 of 1] Compiling Main ( Issue67.hs, Issue67.o )
Linking Issue67 ...
-12367
```
Note:
```hs
-12367 == (fromIntegral (53169 :: Word16) :: Int16)
```
The relevant snippet looks like this at the CMM level (GHC 7.10.3):
```
==================== Output Cmm ====================
[section "data" {
Main.main2_closure:
const Main.main2_info;
const 0;
const 0;
const 0;
},
section "readonly" {
c3rq_str:
I8[] [207,177]
},
section "readonly" {
c3rr_str:
I8[] [207,177]
},
Main.main2_entry() // [R1]
{ info_tbl: [(c3ru,
label: Main.main2_info
rep:HeapRep static { Thunk }),
(c3rD,
label: block_c3rD_info
rep:StackRep [])]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
c3ru:
...
c3ro:
I64[Sp - 16] = stg_bh_upd_frame_info;
I64[Sp - 8] = _c3rn::I64;
(_c3rw::I64) = call MO_BSwap W16(%MO_UU_Conv_W16_W64(I16[c3rr_str]));
I64[Sp - 24] = c3rD;
R4 = GHC.Types.[]_closure+1;
R3 = _c3rw::I64;
R2 = 0;
Sp = Sp - 24;
call GHC.Show.$wshowSignedInt_info(R4,
R3,
R2) returns to c3rD, args: 8, res: 8, upd: 24;
...
```
Pre-optimized LLVM basic block:
```
c3rB:
%ln3sc = ptrtoint i8* @stg_bh_upd_frame_info to i64
%ln3sb = load i64** %Sp_Var
%ln3sd = getelementptr inbounds i64* %ln3sb, i32 -2
store i64 %ln3sc, i64* %ln3sd, !tbaa !1
%ln3sf = load i64* %lc3rA
%ln3se = load i64** %Sp_Var
%ln3sg = getelementptr inbounds i64* %ln3se, i32 -1
store i64 %ln3sf, i64* %ln3sg, !tbaa !1
%ln3sh = ptrtoint %c3rE_str_struct* @c3rE_str$def to i64
%ln3si = inttoptr i64 %ln3sh to i16*
%ln3sj = load i16* %ln3si, !tbaa !5
%ln3sk = zext i16 %ln3sj to i64
%ln3sl = trunc i64 %ln3sk to i16
%ln3sm = call ccc i16 (i16)* @llvm.bswap.i16( i16 %ln3sl )
%ln3sn = sext i16 %ln3sm to i64
store i64 %ln3sn, i64* %lc3rJ
%ln3sp = ptrtoint void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c3rQ_info$def to i64
%ln3so = load i64** %Sp_Var
%ln3sq = getelementptr inbounds i64* %ln3so, i32 -3
store i64 %ln3sp, i64* %ln3sq, !tbaa !1
%ln3sr = ptrtoint i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64
%ln3ss = add i64 %ln3sr, 1
store i64 %ln3ss, i64* %R4_Var
%ln3st = load i64* %lc3rJ
store i64 %ln3st, i64* %R3_Var
store i64 0, i64* %R2_Var
%ln3su = load i64** %Sp_Var
%ln3sv = getelementptr inbounds i64* %ln3su, i32 -3
%ln3sw = ptrtoint i64* %ln3sv to i64
%ln3sx = inttoptr i64 %ln3sw to i64*
store i64* %ln3sx, i64** %Sp_Var
%ln3sy = bitcast i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*
```
Post-optimized block (`opt --enable-tbaa=true -O2 out-llvm-orig.ll -o out-llvm.bc`):
```
c3rB: ; preds = %c3rU
%ln3s8 = ptrtoint i8* %ln3s7 to i64
%ln3sd = getelementptr inbounds i64* %Sp_Arg, i64 -2
store i64 ptrtoint (i8* @stg_bh_upd_frame_info to i64), i64* %ln3sd, align 8, !tbaa !5
%ln3sg = getelementptr inbounds i64* %Sp_Arg, i64 -1
store i64 %ln3s8, i64* %ln3sg, align 8, !tbaa !5
store i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @"c3rQ_info$def" to i64), i64* %ln3rZ, align 8, !tbaa !5
tail call cc10 void bitcast (i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*)(i64* %Base_Arg, i64* %ln3rZ, i64* %Hp_Arg, i64 %R1_Arg, i64 0, i64 -12367, i64 add (i64 ptrtoint (i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64), i64 1), i64 undef, i64 undef, i64 %SpLim_Arg) #0
ret void
```
Folds it right into a constant!
I haven't spent time diagnosing this much further, yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC and LLVM don't agree on what to do with byteSwap16#","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["codegen,","llvm"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this test case (taken from [https://github.com/well-typed/binary-serialise-cbor/issues/67 here] and lightly modified to work on big/little endian machines):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\n{-# LANGUAGE MagicHash #-}\r\n{-# LANGUAGE CPP #-}\r\nmodule Main\r\n ( main -- :: IO ()\r\n ) where\r\n\r\n#include \"ghcconfig.h\"\r\n\r\nimport GHC.Prim\r\nimport GHC.Word\r\n\r\ndata T = T !Addr#\r\n\r\nt :: T\r\n#ifndef WORDS_BIGENDIAN\r\nt = T \"\\xcf\\xb1\"#\r\n#else\r\nt = T \"\\xb1\\xcf\"#\r\n#endif\r\n\r\ngrabWord16 :: T -> Word64\r\ngrabWord16 (T addr#) = W64# (byteSwap16# (indexWord16OffAddr# addr# 0#))\r\n\r\ntrip :: Int\r\ntrip = fromIntegral (grabWord16 t)\r\n\r\nmain :: IO ()\r\nmain = print trip\r\n}}}\r\n\r\nWith GHC 7.10.3 using the NCG, the results given are correct:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.3\r\n$ ghc -Wall -fforce-recomp -O2 Issue67.hs && ./Issue67\r\n[1 of 1] Compiling Main ( Issue67.hs, Issue67.o )\r\nLinking Issue67 ...\r\n53169\r\n}}}\r\n\r\nThis also is the same on GHC 8.0.1 using the NCG, on both PowerPC and AMD64 as well. This answer is correct: `53169` is `0xCFB1` in hex, so the `byteSwap16#` primitive correctly works to decode the swapped-endian number.\r\n\r\nHowever, the story is not the same with GHC 7.10.3+LLVM 3.5, or GHC 8.0.1+LLVM 3.7:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.3\r\n$ llc --version | head -2\r\nLLVM (http://llvm.org/):\r\n LLVM version 3.5.2\r\n$ ghc -Wall -fforce-recomp -O2 Issue67.hs -fllvm && ./Issue67\r\n[1 of 1] Compiling Main ( Issue67.hs, Issue67.o )\r\nLinking Issue67 ...\r\n-12367\r\n}}}\r\n\r\nNote:\r\n\r\n{{{#!hs\r\n-12367 == (fromIntegral (53169 :: Word16) :: Int16)\r\n}}}\r\n\r\nThe relevant snippet looks like this at the CMM level (GHC 7.10.3):\r\n\r\n{{{\r\n==================== Output Cmm ====================\r\n[section \"data\" {\r\n Main.main2_closure:\r\n const Main.main2_info;\r\n const 0;\r\n const 0;\r\n const 0;\r\n },\r\n section \"readonly\" {\r\n c3rq_str:\r\n I8[] [207,177]\r\n },\r\n section \"readonly\" {\r\n c3rr_str:\r\n I8[] [207,177]\r\n },\r\n Main.main2_entry() // [R1]\r\n { info_tbl: [(c3ru,\r\n label: Main.main2_info\r\n rep:HeapRep static { Thunk }),\r\n (c3rD,\r\n label: block_c3rD_info\r\n rep:StackRep [])]\r\n stack_info: arg_space: 8 updfr_space: Just 8\r\n }\r\n {offset\r\n c3ru:\r\n ...\r\n c3ro:\r\n I64[Sp - 16] = stg_bh_upd_frame_info;\r\n I64[Sp - 8] = _c3rn::I64;\r\n (_c3rw::I64) = call MO_BSwap W16(%MO_UU_Conv_W16_W64(I16[c3rr_str]));\r\n I64[Sp - 24] = c3rD;\r\n R4 = GHC.Types.[]_closure+1;\r\n R3 = _c3rw::I64;\r\n R2 = 0;\r\n Sp = Sp - 24;\r\n call GHC.Show.$wshowSignedInt_info(R4,\r\n R3,\r\n R2) returns to c3rD, args: 8, res: 8, upd: 24;\r\n...\r\n}}}\r\n\r\nPre-optimized LLVM basic block:\r\n\r\n{{{\r\nc3rB:\r\n %ln3sc = ptrtoint i8* @stg_bh_upd_frame_info to i64\r\n %ln3sb = load i64** %Sp_Var\r\n %ln3sd = getelementptr inbounds i64* %ln3sb, i32 -2\r\n store i64 %ln3sc, i64* %ln3sd, !tbaa !1\r\n %ln3sf = load i64* %lc3rA\r\n %ln3se = load i64** %Sp_Var\r\n %ln3sg = getelementptr inbounds i64* %ln3se, i32 -1\r\n store i64 %ln3sf, i64* %ln3sg, !tbaa !1\r\n %ln3sh = ptrtoint %c3rE_str_struct* @c3rE_str$def to i64\r\n %ln3si = inttoptr i64 %ln3sh to i16*\r\n %ln3sj = load i16* %ln3si, !tbaa !5\r\n %ln3sk = zext i16 %ln3sj to i64\r\n %ln3sl = trunc i64 %ln3sk to i16\r\n %ln3sm = call ccc i16 (i16)* @llvm.bswap.i16( i16 %ln3sl )\r\n %ln3sn = sext i16 %ln3sm to i64\r\n store i64 %ln3sn, i64* %lc3rJ\r\n %ln3sp = ptrtoint void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c3rQ_info$def to i64\r\n %ln3so = load i64** %Sp_Var\r\n %ln3sq = getelementptr inbounds i64* %ln3so, i32 -3\r\n store i64 %ln3sp, i64* %ln3sq, !tbaa !1\r\n %ln3sr = ptrtoint i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64\r\n %ln3ss = add i64 %ln3sr, 1\r\n store i64 %ln3ss, i64* %R4_Var\r\n %ln3st = load i64* %lc3rJ\r\n store i64 %ln3st, i64* %R3_Var\r\n store i64 0, i64* %R2_Var\r\n %ln3su = load i64** %Sp_Var\r\n %ln3sv = getelementptr inbounds i64* %ln3su, i32 -3\r\n %ln3sw = ptrtoint i64* %ln3sv to i64\r\n %ln3sx = inttoptr i64 %ln3sw to i64*\r\n store i64* %ln3sx, i64** %Sp_Var\r\n %ln3sy = bitcast i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*\r\n}}}\r\n\r\nPost-optimized block (`opt --enable-tbaa=true -O2 out-llvm-orig.ll -o out-llvm.bc`):\r\n\r\n{{{\r\nc3rB: ; preds = %c3rU\r\n %ln3s8 = ptrtoint i8* %ln3s7 to i64\r\n %ln3sd = getelementptr inbounds i64* %Sp_Arg, i64 -2\r\n store i64 ptrtoint (i8* @stg_bh_upd_frame_info to i64), i64* %ln3sd, align 8, !tbaa !5\r\n %ln3sg = getelementptr inbounds i64* %Sp_Arg, i64 -1\r\n store i64 %ln3s8, i64* %ln3sg, align 8, !tbaa !5\r\n store i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @\"c3rQ_info$def\" to i64), i64* %ln3rZ, align 8, !tbaa !5\r\n tail call cc10 void bitcast (i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*)(i64* %Base_Arg, i64* %ln3rZ, i64* %Hp_Arg, i64 %R1_Arg, i64 0, i64 -12367, i64 add (i64 ptrtoint (i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64), i64 1), i64 undef, i64 undef, i64 %SpLim_Arg) #0\r\n ret void\r\n}}}\r\n\r\nFolds it right into a constant!\r\n\r\nI haven't spent time diagnosing this much further, yet.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12147GHC's Linker Should Support Relocation Type 422019-11-07T10:09:30ZgershombGHC's Linker Should Support Relocation Type 42As per: https://github.com/DanielG/ghc-mod/issues/762\#issuecomment-213743585
"gas \>= 2.26 uses some new relocation types (in particular type 42, aka R_X86_64_REX_GOTPCRELX), which are not supported by ghc's linker."
This causes probl...As per: https://github.com/DanielG/ghc-mod/issues/762\#issuecomment-213743585
"gas \>= 2.26 uses some new relocation types (in particular type 42, aka R_X86_64_REX_GOTPCRELX), which are not supported by ghc's linker."
This causes problems when linking in libs with certain sorts of c bits via the GHC API (at the very least).
Support should be added.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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's Linker Should Support Relocation Type 42","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As per: https://github.com/DanielG/ghc-mod/issues/762#issuecomment-213743585\r\n\r\n\"gas >= 2.26 uses some new relocation types (in particular type 42, aka R_X86_64_REX_GOTPCRELX), which are not supported by ghc's linker.\"\r\n\r\nThis causes problems when linking in libs with certain sorts of c bits via the GHC API (at the very least).\r\n\r\nSupport should be added.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12529Error message: visible type application of constructor/variable that is not i...2019-09-18T07:20:37ZIcelandjackError message: visible type application of constructor/variable that is not in scopeIf I use an identifier not in scope:
```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> p
<interactive>:1:1: error: Variable not in scope: p
Prelude> P
<interactive>:2:1: error: Data con...If I use an identifier not in scope:
```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> p
<interactive>:1:1: error: Variable not in scope: p
Prelude> P
<interactive>:2:1: error: Data constructor not in scope: P
```
Using visible type application:
```
$ ghci -ignore-dot-ghci -XTypeApplications
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> p @Int
<interactive>:1:1: error:
• Cannot apply expression of type ‘t0’
to a visible type argument ‘Int’
• In the expression: p @Int
In an equation for ‘it’: it = p @Int
Prelude> P @Int
<interactive>:2:1: error:
• Cannot apply expression of type ‘t0’
to a visible type argument ‘Int’
• In the expression: P @Int
In an equation for ‘it’: it = P @Int
```
I would prefer these error messages to be the same as the first two: thoughts?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Error message: visible type application of constructor/variable that is not in scope","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I use an identifier not in scope:\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> p\r\n\r\n<interactive>:1:1: error: Variable not in scope: p\r\nPrelude> P\r\n\r\n<interactive>:2:1: error: Data constructor not in scope: P\r\n}}}\r\n\r\nUsing visible type application:\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci -XTypeApplications\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> p @Int\r\n\r\n<interactive>:1:1: error:\r\n • Cannot apply expression of type ‘t0’\r\n to a visible type argument ‘Int’\r\n • In the expression: p @Int\r\n In an equation for ‘it’: it = p @Int\r\nPrelude> P @Int\r\n\r\n<interactive>:2:1: error:\r\n • Cannot apply expression of type ‘t0’\r\n to a visible type argument ‘Int’\r\n • In the expression: P @Int\r\n In an equation for ‘it’: it = P @Int\r\n}}}\r\n\r\nI would prefer these error messages to be the same as the first two: thoughts?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/4102Bit manipulation built-ins2019-07-07T19:00:33ZmpiechotkaBit manipulation built-insSo far Haskell/GHC lacks more HL bit manipulation instructions which on many platform can be compiled to single instruction. Probably the good guide are those implemented in LLVM:
- byte swap
- population count
- number of leading ze...So far Haskell/GHC lacks more HL bit manipulation instructions which on many platform can be compiled to single instruction. Probably the good guide are those implemented in LLVM:
- byte swap
- population count
- number of leading zeros
- number of trailing zeros
All of them can be implemented in terms of Data.Bits - however not quite in efficient way (like looping over patterns).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bit manipulation built-ins","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"So far Haskell/GHC lacks more HL bit manipulation instructions which on many platform can be compiled to single instruction. Probably the good guide are those implemented in LLVM:\r\n\r\n - byte swap\r\n - population count\r\n - number of leading zeros\r\n - number of trailing zeros\r\n\r\nAll of them can be implemented in terms of Data.Bits - however not quite in efficient way (like looping over patterns).","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/7105Better names for derived SCCs of instances2019-07-07T18:51:21ZksfBetter names for derived SCCs of instancesCurrently, -fprof-auto generated SCCs are named after their function name, which isn't very helpful if you have a dozen types in Types.hs and the profile is telling you that much time is spend in "compare" and "put" in that very module. ...Currently, -fprof-auto generated SCCs are named after their function name, which isn't very helpful if you have a dozen types in Types.hs and the profile is telling you that much time is spend in "compare" and "put" in that very module. It's even more painful if those instances are derived and you can't easily add manual annotations.
I suggest annotating instance declarations in general with their concrete type, such as "compare/Foo" and "compare/Bar"
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.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":"Better names for derived SCCs of instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, -fprof-auto generated SCCs are named after their function name, which isn't very helpful if you have a dozen types in Types.hs and the profile is telling you that much time is spend in \"compare\" and \"put\" in that very module. It's even more painful if those instances are derived and you can't easily add manual annotations.\r\n\r\nI suggest annotating instance declarations in general with their concrete type, such as \"compare/Foo\" and \"compare/Bar\"","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7461Error messages about "do" statements contain false information2019-07-07T18:49:38ZEyalLotemError messages about "do" statements contain false informationWhen GHC complains about a type-error in a "do" block, it says, for example:
```
main = putChar $ do
getLine
return 'x'
```
Results in an error:
```
Couldn't match type `IO Char' with `Char'
Expected type: IO String -> IO ...When GHC complains about a type-error in a "do" block, it says, for example:
```
main = putChar $ do
getLine
return 'x'
```
Results in an error:
```
Couldn't match type `IO Char' with `Char'
Expected type: IO String -> IO Char -> Char
Actual type: IO String -> IO Char -> IO Char
In a stmt of a 'do' block: getLine
```
I think this error message is pretty directly saying: The **Actual** type of "getLine" is:
```
IO String -> IO Char -> IO Char
```
But that is of course non-sense! It is actually talking about the type of the (\>\>=) binding the "getLine" to the rest of the statements. But the (\>\>=) is not "in the statement" at all, so the error message is plainly wrong.
It would be much better to talk about the type of the entire do block, or maybe the type of the last stmt in the do block (which is the same).
For example, the error could be replaced by:
```
Couldn't match type `IO Char' with `Char'
Expected type: Char
Actual type: IO Char
In a stmt of a 'do' block: return 'x'
```
Or by:
```
Couldn't match type `IO Char' with `Char'
Expected type: Char
Actual type: IO Char
In 'do' block: `do { getLine;
return 'x' }'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Error messages about \"do\" statements contain false information","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When GHC complains about a type-error in a \"do\" block, it says, for example:\r\n\r\n{{{\r\nmain = putChar $ do\r\n getLine\r\n return 'x'\r\n}}}\r\n\r\nResults in an error:\r\n\r\n{{{\r\n Couldn't match type `IO Char' with `Char'\r\n Expected type: IO String -> IO Char -> Char\r\n Actual type: IO String -> IO Char -> IO Char\r\n In a stmt of a 'do' block: getLine\r\n}}}\r\n\r\nI think this error message is pretty directly saying: The '''Actual''' type of \"getLine\" is:\r\n\r\n{{{\r\nIO String -> IO Char -> IO Char\r\n}}}\r\n\r\nBut that is of course non-sense! It is actually talking about the type of the (>>=) binding the \"getLine\" to the rest of the statements. But the (>>=) is not \"in the statement\" at all, so the error message is plainly wrong.\r\n\r\nIt would be much better to talk about the type of the entire do block, or maybe the type of the last stmt in the do block (which is the same).\r\n\r\nFor example, the error could be replaced by:\r\n\r\n{{{\r\n Couldn't match type `IO Char' with `Char'\r\n Expected type: Char\r\n Actual type: IO Char\r\n In a stmt of a 'do' block: return 'x'\r\n}}}\r\n\r\nOr by:\r\n\r\n{{{\r\n Couldn't match type `IO Char' with `Char'\r\n Expected type: Char\r\n Actual type: IO Char\r\n In 'do' block: `do { getLine;\r\n return 'x' }'\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/8308Resurrect ticky code for counting constructor arity2019-07-07T18:45:37ZJan Stolarekjan.stolarek@ed.ac.ukResurrect ticky code for counting constructor arityThere is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in \[\[GhcFile(compiler/codeGen/StgCmmTicky.hs)...There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in \[\[GhcFile(compiler/codeGen/StgCmmTicky.hs)\]\], which masks the commented out function `bumpHistogramE`. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done:
1. Replace current no-op `bumpHistogram` with `bumpHistogramE`. Note that current implementation of `bumpHistogramE` computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this:
```
bumpHistogram lbl n = do
let offset = n `min` 8
emit (addToMem cLong
(cmmIndexExpr cLongWidth
(CmmLit (CmmLabel (mkRtsDataLabel lbl)))
(CmmReg (CmmInt (fromIntegral offset) cLongWidth)))
1)
```
Note that `mkRtsDataLabel` function does not exist anymore but we should be able to replace that call with `mkCmmDataLabel rtsPackageId lbl` (speculation).
1. We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in \[\[GhcFile(includes/stg/Ticky.h)\]\]. We also need to initialize the declared array to contain only zeros.
1. Having declared the arrays we need to fix printing of computed arities. This is done in \[\[GhcFile(rts/Ticky.c)\]\]. Note that there is a lot of code that is commented out (`/* krc: comment out some of this stuff temporarily */`) or disabled with `#if FALSE` pragma. We need to resurect \*some\* of it. There is a `PR_HST` macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams.
1. Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see `bumpHistogram` in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array.
1. Some ticky functions that count arity histograms are not used. For example `tickyReturnNewCon` should probably be called by `cgConApp` like this:
```
; emit =<< fcode_init
; tickyReturnNewCon
; emitReturn [idInfoToAmode idinfo] }
```
The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.7 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Resurrect ticky code for counting constructor arity","status":"New","operating_system":"Unknown/Multiple","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in [[GhcFile(compiler/codeGen/StgCmmTicky.hs)]], which masks the commented out function `bumpHistogramE`. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done:\r\n\r\n1. Replace current no-op `bumpHistogram` with `bumpHistogramE`. Note that current implementation of `bumpHistogramE` computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this:\r\n\r\n{{{\r\nbumpHistogram lbl n = do\r\n let offset = n `min` 8\r\n emit (addToMem cLong\r\n (cmmIndexExpr cLongWidth\r\n (CmmLit (CmmLabel (mkRtsDataLabel lbl)))\r\n (CmmReg (CmmInt (fromIntegral offset) cLongWidth)))\r\n 1)\r\n}}}\r\nNote that `mkRtsDataLabel` function does not exist anymore but we should be able to replace that call with `mkCmmDataLabel rtsPackageId lbl` (speculation).\r\n\r\n2. We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in [[GhcFile(includes/stg/Ticky.h)]]. We also need to initialize the declared array to contain only zeros.\r\n\r\n3. Having declared the arrays we need to fix printing of computed arities. This is done in [[GhcFile(rts/Ticky.c)]]. Note that there is a lot of code that is commented out (`/* krc: comment out some of this stuff temporarily */`) or disabled with `#if FALSE` pragma. We need to resurect *some* of it. There is a `PR_HST` macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams.\r\n\r\n4. Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see `bumpHistogram` in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array.\r\n\r\n5. Some ticky functions that count arity histograms are not used. For example `tickyReturnNewCon` should probably be called by `cgConApp` like this:\r\n\r\n{{{\r\n ; emit =<< fcode_init\r\n ; tickyReturnNewCon\r\n ; emitReturn [idInfoToAmode idinfo] }\r\n}}} \r\n\r\nThe above is a an outline, which should be fairly accurate, but unexpected things may show up along the way.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2mlenmlenhttps://gitlab.haskell.org/ghc/ghc/-/issues/8473Generate table of cost-centre numbers with source locations2019-07-07T18:44:54Zlars_e_kruegerGenerate table of cost-centre numbers with source locations1. prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact...1. prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think.
Suggestion for the format:
```
no. file begin end
1 main.hs 127:7 128:14
```
Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14.
If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #7105 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Generate table of cost-centre numbers with source locations","status":"New","operating_system":"","component":"Profiling","related":[7105],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":".prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think.\r\n\r\nSuggestion for the format:\r\n\r\n{{{\r\nno. file begin end\r\n1 main.hs 127:7 128:14 \r\n}}}\r\n\r\nMeaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14.\r\n\r\nIf somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2