GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-08-29T12:43:54Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16111Inconsistent behavior of Data.Bits.shiftL with different optimization levels ...2020-08-29T12:43:54ZRyan ScottInconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvmConsider this program:
```hs
module Main (main) where
import Data.Bits
import Data.Word
main :: IO ()
main = print $ toInteger (shiftL 1 hm :: Word64)
== toInteger (shiftL 1 hm :: Word64)
hm :: Int
hm = -1
{-# NOINLINE hm...Consider this program:
```hs
module Main (main) where
import Data.Bits
import Data.Word
main :: IO ()
main = print $ toInteger (shiftL 1 hm :: Word64)
== toInteger (shiftL 1 hm :: Word64)
hm :: Int
hm = -1
{-# NOINLINE hm #-}
```
The result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used:
```
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
True
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
True
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
Bug: Bad shift length-1
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
True
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
False
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
Bug: Bad shift length-1
```
This program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this program:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nimport Data.Bits\r\nimport Data.Word\r\n\r\nmain :: IO ()\r\nmain = print $ toInteger (shiftL 1 hm :: Word64)\r\n == toInteger (shiftL 1 hm :: Word64)\r\n\r\nhm :: Int\r\nhm = -1\r\n{-# NOINLINE hm #-}\r\n}}}\r\n\r\nThe result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used:\r\n\r\n{{{\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nTrue\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nTrue\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nBug: Bad shift length-1\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nTrue\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nFalse\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nBug: Bad shift length-1\r\n}}}\r\n\r\nThis program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used!","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/16105Haddock's resource directory isn't properly handled by Hadrian2019-07-07T18:01:30ZAlec TheriaultHaddock's resource directory isn't properly handled by HadrianI'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock-api/resource`).
- only the `html` folder is being copied, which means that there is no way `haddock ...I'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock-api/resource`).
- only the `html` folder is being copied, which means that there is no way `haddock --latex` will work
- the resources (both `html` and `latex`) should probably be specified as `runtimeDependencies` of the `Haddock` builder instead of woven into the doc rules
- the Haddock wrapper in the `BinaryDist` rules specifies the wrong `--lib` dir (we currently put Haddock's resources in the `doc` folder, not the `lib` folder as we do for the Make system)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Haddock's resource directory isn't properly handled by Hadrian","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock-api/resource`).\r\n\r\n * only the `html` folder is being copied, which means that there is no way `haddock --latex` will work\r\n * the resources (both `html` and `latex`) should probably be specified as `runtimeDependencies` of the `Haddock` builder instead of woven into the doc rules\r\n * the Haddock wrapper in the `BinaryDist` rules specifies the wrong `--lib` dir (we currently put Haddock's resources in the `doc` folder, not the `lib` folder as we do for the Make system)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/15956Linker error building `runghc`2019-07-07T18:02:17ZAlec TheriaultLinker error building `runghc`I'm on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either..
```
ghc$ git rev-parse HEAD
df570d920fa66db631f936fa377e598fe92bd2a1
ghc$ ./boot && ./configure
ghc$ make -j V=0 ...I'm on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either..
```
ghc$ git rev-parse HEAD
df570d920fa66db631f936fa377e598fe92bd2a1
ghc$ ./boot && ./configure
ghc$ make -j V=0 # succeeds
ghc$ ./hadrian/build.sh -c --build-root="_build2" > out.log 2> err.log # fails
```
Hadrian fails when trying to link `runghc`:
```
Error when running Shake build system:
at src/Rules.hs:(34,19)-(47,17):
at src/Rules.hs:47:5-17:
* Depends on: _build2/stage1/bin/runghc
* Raised the exception:
user error (Development.Shake.cmd, system command failed
Command: _build2/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build2/stage1/lib/package.conf.d' '-package-id base-4.12.0.0' '-package-id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id process-1.6.3.0' '-package-id unix-2.7.2.2' -i -i_build2/stage1/utils/runghc/build -i_build2/stage1/utils/runghc/build/runghc/autogen -iutils/runghc/. -Iincludes -I_build2/generated -I_build2/stage1/utils/runghc/build -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/process-1.6.3.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/unix-2.7.2.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/time-1.9.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/bytestring-0.10.9.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/base-4.12.0.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/integer-gmp-1.0.2.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/rts-1.0/include -I_build2/generated -optc-I_build2/generated -optP-include -optP_build2/stage1/utils/runghc/build/runghc/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build2/stage1/utils/runghc/build -hidir _build2/stage1/utils/runghc/build -stubdir _build2/stage1/utils/runghc/build -no-auto-link-packages -rtsopts -optl-lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build2/stage1/utils/runghc/build/Main.o -o _build2/stage1/bin/runghc -O2 -H32m -XHaskell2010 -ghcversion-file=/Users/atheriault/Code/ghc/_build2/generated/ghcversion.h
Exit code: 1
Stderr:
Undefined symbols for architecture x86_64:
"_findPtr", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
)
```
This must be a recent regression, since I was successfully building with Hadrian as recently as last week. I'll try to bisect, although the failure occurs so late in the compilation pipeline that I expect progress to be quite slow.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Linker error buidling `runghc`","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either..\r\n\r\n{{{\r\nghc$ git rev-parse HEAD\r\ndf570d920fa66db631f936fa377e598fe92bd2a1\r\nghc$ ./boot && ./configure\r\nghc$ make -j V=0 # succeeds\r\nghc$ ./hadrian/build.sh -c --build-root=\"_build2\" > out.log 2> err.log # fails\r\n}}}\r\n\r\nHadrian fails when trying to link `runghc`:\r\n\r\n{{{\r\nError when running Shake build system:\r\n at src/Rules.hs:(34,19)-(47,17):\r\n at src/Rules.hs:47:5-17:\r\n* Depends on: _build2/stage1/bin/runghc\r\n* Raised the exception:\r\nuser error (Development.Shake.cmd, system command failed\r\nCommand: _build2/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build2/stage1/lib/package.conf.d' '-package-id base-4.12.0.0' '-package-id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id process-1.6.3.0' '-package-id unix-2.7.2.2' -i -i_build2/stage1/utils/runghc/build -i_build2/stage1/utils/runghc/build/runghc/autogen -iutils/runghc/. -Iincludes -I_build2/generated -I_build2/stage1/utils/runghc/build -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/process-1.6.3.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/unix-2.7.2.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/time-1.9.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/bytestring-0.10.9.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/base-4.12.0.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/integer-gmp-1.0.2.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/rts-1.0/include -I_build2/generated -optc-I_build2/generated -optP-include -optP_build2/stage1/utils/runghc/build/runghc/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build2/stage1/utils/runghc/build -hidir _build2/stage1/utils/runghc/build -stubdir _build2/stage1/utils/runghc/build -no-auto-link-packages -rtsopts -optl-lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build2/stage1/utils/runghc/build/Main.o -o _build2/stage1/bin/runghc -O2 -H32m -XHaskell2010 -ghcversion-file=/Users/atheriault/Code/ghc/_build2/generated/ghcversion.h\r\nExit code: 1\r\nStderr:\r\nUndefined symbols for architecture x86_64:\r\n \"_findPtr\", referenced from:\r\n -u command line option\r\nld: symbol(s) not found for architecture x86_64\r\nclang: error: linker command failed with exit code 1 (use -v to see invocation)\r\n`gcc' failed in phase `Linker'. (Exit code: 1)\r\n)\r\n}}}\r\n\r\n\r\nThis must be a recent regression, since I was successfully building with Hadrian as recently as last week. I'll try to bisect, although the failure occurs so late in the compilation pipeline that I expect progress to be quite slow.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/15460Literals overflow2019-07-07T18:04:41ZSylvain HenryLiterals overflowConsider the following example:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
print x
```
It gets desugared into:
```hs
m...Consider the following example:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
print x
```
It gets desugared into:
```hs
main
= print
@ Int
GHC.Show.$fShowInt
(GHC.Types.I#
7237005577332262213973186563042994240829374041602535252466099000494570602495#)
```
Problem: the literal value isn't rounded and there is no overflow warning.
It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
if (x > maxBound)
then print "Oups"
else print "Ok"
> ghc TestLitOverflow.hs -Wall -O0
> ./TestLitOverflow
"Ok"
> ghc TestLitOverflow.hs -Wall -O2
> ./TestLitOverflow
"Oups"
```8.8.1Alec TheriaultAlec Theriault