GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-07T14:16:41Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20757GHC.SysTools.BaseDir.findToolDir "/" on Windows results in infinite loop2021-12-07T14:16:41ZJakob BrünkerGHC.SysTools.BaseDir.findToolDir "/" on Windows results in infinite loop## Summary
Calling [`GHC.SysTools.BaseDir.findToolDir "/"`](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/SysTools/BaseDir.hs#L182-201) on Windows results in
```
*** Exception: ghc-9.2.1.exe: could not detect mingw toolc...## Summary
Calling [`GHC.SysTools.BaseDir.findToolDir "/"`](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/SysTools/BaseDir.hs#L182-201) on Windows results in
```
*** Exception: ghc-9.2.1.exe: could not detect mingw toolchain in the following paths:
```
when run in GHCi, followed by GHCi hanging, and in `<<loop>>` when compiled.
This bit me when I still had `initSettings "/"` for testing purposes but forgot about it - the non-terminating error-message wasn't very helpful in reminding me.
## Expected behavior
Something along the lines of
```
*** Exception: ghc-9.2.1.exe: could not detect mingw toolchain in the following paths: ["/mingw", "/../mingw", "/../../mingw", "/../../../mingw"]
```
## Environment
* GHC version used: 9.2.1
* Operating System: Windows 10
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/20745C backend handles signedness incorrectly2022-10-12T13:14:34ZBen GamariC backend handles signedness incorrectlyIn !6934 I noticed and fixed a few issues in the C backend to do with signedness:
### Unsigned operations can sometimes turn into signed operations if given signed arguments
Consider a program like
```c
test() {
bits64 ret,...In !6934 I noticed and fixed a few issues in the C backend to do with signedness:
### Unsigned operations can sometimes turn into signed operations if given signed arguments
Consider a program like
```c
test() {
bits64 ret, a, b;
a = %neg(43 :: bits64);
b = %neg(0x443c70fa3e465120 :: bits64);
ret = %modu(a, b);
return (ret);
}
```
In this case both `a` and `b` will be `StgInt`s in the generated C (since
`MO_Neg` is a signed operation). However, if we provide these as operands to `%` then we
will get *signed* modulus semantics, despite the user requesting *unsigned* semantics.
Therefore we must be careful to cast both arguments to `StgWord`; currently we do not do this.
### Sub-word signed results must be zero-extended
Consider a program like (from #20634):
```c
test() {
bits64 ret;
bits8 a,b;
a = 0xe1 :: bits8; // == -31 signed
b = %quot(a, 3::bits8); // == -10 signed
ret = %zx64(a); // == 0xf6 unsigned
return (ret);
}
```
This program should return `0xf6 == 246`. However, we need to be very careful
with when dealing with the result of the %quot. For instance, one might be
tempted produce code like:
```c
StgWord8 a = 0xe1U;
StgInt8 b = (StgInt8) a / (StgInt8) 0x3U;
StgWord ret = (W_) b;
```
However, this would be wrong; by widening `b` directly from `StgInt8` to
`StgWord` we will get sign-extension semantics: rather than 0xf6 we will get
`0xfffffffffffffff6`. To avoid this we must first cast `b` back to `StgWord8`,
ensuring that we get zero-extension semantics when we widen up to `StgWord`.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20659GHCi 9.2.1 Unicode input broken on macOS Arm642021-11-10T23:04:18ZDakotah LambertGHCi 9.2.1 Unicode input broken on macOS Arm64## Summary
Entering non-ASCII symbols into the GHCi readline environment on arm64 doesn't work (x86_64 is unaffected).
## Steps to reproduce
1. Enter the GHCi interpreter
2. Type or paste `print "¬"`
3. Observe that the Unicode replac...## Summary
Entering non-ASCII symbols into the GHCi readline environment on arm64 doesn't work (x86_64 is unaffected).
## Steps to reproduce
1. Enter the GHCi interpreter
2. Type or paste `print "¬"`
3. Observe that the Unicode replacement character has been inserted, but press return anyway
4. Observe the output "\65533\65533"
5. Note that `putStrLn "\172"` prints the expected character
## Expected behavior
Rather than "\65533\65533" (two instances of the Unicode replacement character), the output should be "\172" as it is on x86_64 builds. The symbol should behave as it does in the terminal outside of GHCi, being printed as itself rather than as the replacement character.
## Environment
* GHC version used: 9.2.1
Optional:
* Operating System: macOS 11.6
* System Architecture: arm649.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/20646Broken C Calls on Darwin/AArch642021-11-10T14:35:07ZBen GamariBroken C Calls on Darwin/AArch64bgamari/test-primops> has discovered this failing C call shape on Darwin/AArch64 when using the LLVM backend (and presumably the NCG as well although the latter is currently too broken to judge):
```
C-Call correctness: FAIL (0.3...bgamari/test-primops> has discovered this failing C call shape on Darwin/AArch64 when using the LLVM backend (and presumably the NCG as well although the latter is currently too broken to judge):
```
C-Call correctness: FAIL (0.36s)
*** Failed! Falsified (after 1 test):
CCallDesc {callRet = SomeNumber @W16 0xef7c, callArgs = [SomeNumber @W8 0x90,SomeNumber @W8 0x2e,SomeNumber @W32 0xc4f525b5,SomeNumber @W16 0xfa13,SomeNumber @W32 0x3762a248,SomeNumber @W32 0xc91956ee,SomeNumber @W64 0x6d4c9d69ed69c6f6,SomeNumber @W32 0x6fc830de,SomeNumber @W32 0x20108891,SomeNumber @W16 0x65ae,SomeNumber @W64 0xd15099605cf94130,SomeNumber @W64 0xfa129274dad70ff,SomeNumber @W16 0x29ef,SomeNumber @W32 0x1a038aa5,SomeNumber @W64 0x33f45559c8ad4c8b,SomeNumber @W8 0x37,SomeNumber @W64 0x64827e4121b94909,SomeNumber @W8 0x38,SomeNumber @W32 0x88ac3077]}
[144,46,3304400309,64019,929210952,3373881070,7875842926644414198,1875390686,537954449,0,26030,15082723791219540272,28927,262220071,10735,165,3743711034358975627,55,0,61308] /= [144,46,3304400309,64019,929210952,3373881070,7875842926644414198,1875390686,537954449,26030,15082723791219540272,1126226630603010303,10735,436439717,3743711034358975627,55,7242489968968943881,56,2292985975,61308]
Use --quickcheck-replay=987633 to reproduce.
Use -p '/o0-llvm.C-Call correctness/' to rerun this test only.
```https://gitlab.haskell.org/ghc/ghc/-/issues/20645LLVM backend miscompiles pext and pdep2022-10-12T13:14:29ZBen GamariLLVM backend miscompiles pext and pdepStrangely, the `W16` and `W8` `pexp` and `pdep` tests of bgamari/test-primops> currently fail with the LLVM backend:
For instance,
```
*Main> let e = parseExpr @W16 "narrow[W64→W16](load[W64](0::W64))"
*Main> let f = parseExpr @W16 "nar...Strangely, the `W16` and `W8` `pexp` and `pdep` tests of bgamari/test-primops> currently fail with the LLVM backend:
For instance,
```
*Main> let e = parseExpr @W16 "narrow[W64→W16](load[W64](0::W64))"
*Main> let f = parseExpr @W16 "narrow[W64→W16]((load[W64](0::W64)) ^ 1::W64)"
*Main> evalCallishOp comp pext (e,f)
2
*Main> evalCallishOp llvm pext (e,f)
0x1e
*Main> interpret e
0x100
*Main> interpret f
0x101
```
The result of this operation should be `2`.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20644Signed arithmetic miscompiled on AArch642022-11-08T20:19:13ZBen GamariSigned arithmetic miscompiled on AArch64Currently the AArch64 NCG miscompiles signed, sub-word arithmetic. For instance, consider this program:
```c
test(bits64 buffer) {
return (%zx64(%quot(%lobits8(%neg(bits64[buffer + (1 :: bits64)])), (2 :: bits8))));
}
```
This should ...Currently the AArch64 NCG miscompiles signed, sub-word arithmetic. For instance, consider this program:
```c
test(bits64 buffer) {
return (%zx64(%quot(%lobits8(%neg(bits64[buffer + (1 :: bits64)])), (2 :: bits8))));
}
```
This should evaluate to `-1 /[signed] 2 == 0`.
However, with %9.2.1 it produces the incorrect result of `127` via following assembler:
```asm
test:
.Lc3:
# Load W64 from `buffer`
mov x18, x22
ldr x18, [ x18, 1 ]
# Negate
neg x18, x18
# Narrow W64 -> W8
ubfm x18, x18, #0, #7
# Signed Divide by 2
mov w17, #2
sdiv w18, w18, w17
# The above division is wrong: it encodes word-sized division but w18 contains
# a (non-signed-extended) W8
ubfm x18, x18, #0, #7
mov x22, x18
ldr x18, [ x20 ]
br x18
```9.2.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20640UTF-8 decoding doesn't work correctly on GHC 9.2.1+AArch64 NCG2022-04-01T17:27:28Zarata, mizukiUTF-8 decoding doesn't work correctly on GHC 9.2.1+AArch64 NCG## Summary
With GHC 9.2.1, `GHC.IO.Encoding.utf8` fails to decode non-ASCII text.
It happens on
* arm64-darwin / AArch64 NCG / ghc-9.2 branch
* aarch64-linux / AArch64 NCG / GHC 9.2.1
but does not happen on
* x86\_64
* arm64-darwin ...## Summary
With GHC 9.2.1, `GHC.IO.Encoding.utf8` fails to decode non-ASCII text.
It happens on
* arm64-darwin / AArch64 NCG / ghc-9.2 branch
* aarch64-linux / AArch64 NCG / GHC 9.2.1
but does not happen on
* x86\_64
* arm64-darwin / LLVM backend / GHC 8.10.7
* arm64-darwin / base library built with LLVM backend (`hadrian/build --flavour=default+llvm`) / ghc-9.2 branch
* arm64-darwin / AArch64 NCG / master branch
So I guess that a bug in AArch64 NCG whose fix is not backported to ghc-9.2 is affecting here.
## Steps to reproduce
The following program
```haskell
import GHC.Foreign
import GHC.IO.Encoding
import qualified Foreign.C.String as F
main = withCStringLen utf8 "\x1F424" $ \csl -> do
s <- F.peekCAStringLen csl
print s
s <- peekCStringLen utf8 csl
print s
```
prints
```haskell
"\240\159\144\164"
string.hs: recoverDecode: invalid argument (invalid byte sequence)
```
## Expected behavior
It should output
```haskell
"\240\159\144\164"
"\128036"
```
## Environment
* GHC version used: 9.2.1 release / ghc-9.2 branch (ac4496ceb190ab7c3e300c9f844ef4e8e4e75c32)
* Operating System: macOS
* System Architecture: AArch649.2.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20638Miscompilation of signed load by ARMv8 NCG2022-10-12T13:14:13ZBen GamariMiscompilation of signed load by ARMv8 NCGThis Cmm program is miscompiled by the ARMv8 NCG.
```c
test(W_ buffer) {
return (%zx64(%shrl(bits16[buffer + (128 :: bits64)], (1 :: bits64))) & (64711 :: bits64));
}
```
With `-fllvm` (and under the bgamari/test-primops> interpreter...This Cmm program is miscompiled by the ARMv8 NCG.
```c
test(W_ buffer) {
return (%zx64(%shrl(bits16[buffer + (128 :: bits64)], (1 :: bits64))) & (64711 :: bits64));
}
```
With `-fllvm` (and under the bgamari/test-primops> interpreter) this evaluates to `0x40c0`. With the NCG it evaluates to `0xc0c0`.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20637LLVM backend miscompilation2022-10-12T13:14:07ZBen GamariLLVM backend miscompilationThis Cmm program produces different result when compiled using the NCG and LLVM backends:
```c
test() {
return (%zx64(%lobits16(%zx32(%lobits8((%lobits16(%shl((1 :: bits32), (45 :: bits64))) ^ (1 :: bits16)))))));
}
```
The NCG return...This Cmm program produces different result when compiled using the NCG and LLVM backends:
```c
test() {
return (%zx64(%lobits16(%zx32(%lobits8((%lobits16(%shl((1 :: bits32), (45 :: bits64))) ^ (1 :: bits16)))))));
}
```
The NCG returns `1` while LLVM returns `0` with `-O0` and `0x7ff3a69bc010` with `-O1`. I believe `1` is correct.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20634Inconsistent treatment of signedness of Cmm literals2022-10-12T13:14:02ZBen GamariInconsistent treatment of signedness of Cmm literalsConsider these Cmm programs:
```c
testA() { return ( 0x8000000000000000::bits64 ); }
testB() { return ( -0x8000000000000000::bits64 ); }
testC() { return (%quot( 0x8000000000000000::bits64, 2)); }
testD() { return (%quot...Consider these Cmm programs:
```c
testA() { return ( 0x8000000000000000::bits64 ); }
testB() { return ( -0x8000000000000000::bits64 ); }
testC() { return (%quot( 0x8000000000000000::bits64, 2)); }
testD() { return (%quot(-0x8000000000000000::bits64, 2)); }
```
In general, one wouldn't expect that `0x8000000000000000::bits64` and `-0x8000000000000000::bits64` differ semantically, given that we assume a two's complement sign representation.
In the case of `testA` and `testB` GHC respects this expectation. However, in the case of `testC` and `testD` there is a surprising difference:
```
Program Value emitted in assembler
----------- ---------------------------
`testA` `-9223372036854775808`
`testB` `-9223372036854775808`
`testC` ` 4611686018427387904`
`testD` `-4611686018427387904`
```
That is, while we produce the correct result in `testD`, in `testC` we silently drop the sign bit. Given that this same behavior is not observed in `testA` and `testB`, I can only assume that this is some constant folding going awry.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20626Sub-word right-arithmetic-shifts appear to be wrong on x862023-08-02T10:17:55ZBen GamariSub-word right-arithmetic-shifts appear to be wrong on x86While validating bgamari/test-primops> in preparation for looking at #20594, I noticed that even the x86 NCG doesn't match the reference implementation. Specifically, consider this C-- program:
```c
test() {
bits64 ret;
ret = %zx...While validating bgamari/test-primops> in preparation for looking at #20594, I noticed that even the x86 NCG doesn't match the reference implementation. Specifically, consider this C-- program:
```c
test() {
bits64 ret;
ret = %zx64(%shra(242::bits8, 1));
return (ret);
}
```
I would expect this to return `(242>>1) | (1<<7) == 249`. However, when compiled with GHC 8.10.7 it returns 121, as demonstrated by this program:
```hs
{-# LANGUAGE GHCForeignImportPrim #-}
{-# LANGUAGE UnliftedFFITypes #-}
{-# LANGUAGE MagicHash #-}
module Main where
import GHC.Exts
import GHC.Ptr
import Foreign.Marshal.Alloc
foreign import prim "test" test :: Addr# -> Word#
main :: IO ()
main = do
Ptr p <- callocBytes (1*1000*1000)
print $ W# (test p)
```9.0.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20594tf-random's documentation fails to build with GHC 9.2.1's haddock on aarch64-...2022-08-04T15:22:18Zsternitf-random's documentation fails to build with GHC 9.2.1's haddock on aarch64-linux## Summary
haddock shipped with GHC 9.2.1 fails to build `tf-random`'s documentation due to `haddock: internal error: dist/doc/html/tf-random/haddock-prologue1387-0.txt: hGetContents: invalid argument (invalid byte sequence)`.
This see...## Summary
haddock shipped with GHC 9.2.1 fails to build `tf-random`'s documentation due to `haddock: internal error: dist/doc/html/tf-random/haddock-prologue1387-0.txt: hGetContents: invalid argument (invalid byte sequence)`.
This seems to be due to some decoding problem that is architecture-specific as I've only have been able to reproduce it on `aarch64-linux`. Additionally, the issue doesn't seem to be limited to `haddock`, since also `Cabal` reports while building: `Warning: tf-random.cabal:0:0: UTF8 encoding problem at byte offset 1083`.
With this hint taken into account, it seems the Problem is decoding the “ł” in “Michał Pałka”.
<details>
<summary>Full build log</summary>
```
setupCompilerEnvironmentPhase
Build with /nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1.
unpacking sources
unpacking source archive /nix/store/1nr84gxykdayb34wqhyhzapplwj6hj2x-tf-random-0.5.tar.gz
source root is tf-random-0.5
setting SOURCE_DATE_EPOCH to timestamp 1397051832 of file tf-random-0.5/tf-random.cabal
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/build/setup-package.conf.d -j4 +RTS -A64M -RTS -threaded -rtsopts
[1 of 1] Compiling Main ( Setup.hs, /build/Main.o )
Linking Setup ...
updateAutotoolsGnuConfigScriptsPhase
configuring
configureFlags: --verbose --prefix=/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/pdia0inbjhx12hhyfpvavkmdnizxxbny-tf-random-0.5-doc/share/doc/tf-random-0.5 --with-gcc=gcc --package-db=/build/package.conf.d --ghc-options=-j4 +RTS -A64M -RTS --disable-split-objs --disable-library-profiling --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --extra-lib-dirs=/nix/store/iz9f5fjbk906c9j8zvr83skisy8mlbx7-ncurses-6.2/lib --extra-lib-dirs=/nix/store/wz31pppvk0ij3ykyafkw4xhp631b2i9m-libffi-3.4.2/lib --extra-lib-dirs=/nix/store/xwflzk66nkh7s45cqbjfmrc62qqncz3c-gmp-6.2.1/lib
Using Parsec parser
Warning: tf-random.cabal:0:0: UTF8 encoding problem at byte offset 1083
Configuring tf-random-0.5...
Dependency base >=4.2 && <5: using base-4.16.0.0
Dependency primitive >=0.3: using primitive-0.7.2.0
Dependency random: using random-1.2.1
Dependency time: using time-1.11.1.1
Source component graph: component lib
Configured component graph:
component tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
include base-4.16.0.0
include primitive-0.7.2.0-26FrVImOeSRFMFxEAgiBFt
include random-1.2.1-4qyYj6P88hEL41FyrmzJfp
include time-1.11.1.1
Linked component graph:
unit tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
include base-4.16.0.0
include primitive-0.7.2.0-26FrVImOeSRFMFxEAgiBFt
include random-1.2.1-4qyYj6P88hEL41FyrmzJfp
include time-1.11.1.1
System.Random.TF=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF,System.Random.TF.Gen=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF.Gen,System.Random.TF.Init=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF.Init,System.Random.TF.Instances=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF.Instances
Ready component graph:
definite tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
depends base-4.16.0.0
depends primitive-0.7.2.0-26FrVImOeSRFMFxEAgiBFt
depends random-1.2.1-4qyYj6P88hEL41FyrmzJfp
depends time-1.11.1.1
Using Cabal-3.6.0.0 compiled by ghc-9.2
Using compiler: ghc-9.2.1
Using install prefix:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5
Executables installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/bin
Libraries installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/lib/ghc-9.2.1/aarch64-linux-ghc-9.2.1/tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
Dynamic Libraries installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/lib/ghc-9.2.1/aarch64-linux-ghc-9.2.1
Private executables installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/libexec/aarch64-linux-ghc-9.2.1/tf-random-0.5
Data files installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/share/aarch64-linux-ghc-9.2.1/tf-random-0.5
Documentation installed in:
/nix/store/pdia0inbjhx12hhyfpvavkmdnizxxbny-tf-random-0.5-doc/share/doc/tf-random-0.5
Configuration files installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/etc
No alex found
Using ar found on system at:
/nix/store/10avvfvwvzj4y0z6zxij2qnz5pgqprg5-binutils-2.35.1/bin/ar
No c2hs found
No cpphs found
No doctest found
Using gcc version 9.3.0 given by user at:
/nix/store/1q1mif7h3lgxdaxg6j39hli5azikrfla-gcc-wrapper-9.3.0/bin/gcc
Using ghc version 9.2.1 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/ghc
Using ghc-pkg version 9.2.1 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.26.0 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/haddock
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.68 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/hpc
Using hsc2hs version 0.68.8 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/hsc2hs
Using hscolour version 1.24 found on system at:
/nix/store/cknsx4nddzjdm0g7vg9d9vpc9lvslscq-hscolour-1.24.4/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/579l1jpqmwjfghmlh9mnj6ykx06q2g38-binutils-wrapper-2.35.1/bin/ld.gold
No pkg-config found
Using runghc version 9.2.1 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/runghc
Using strip version 2.35 found on system at:
/nix/store/10avvfvwvzj4y0z6zxij2qnz5pgqprg5-binutils-2.35.1/bin/strip
Using tar found on system at:
/nix/store/zfcd6sdfsfddhf5ybkarj4q241bsymn1-gnutar-1.34/bin/tar
No uhc found
building
Preprocessing library for tf-random-0.5..
Building library for tf-random-0.5..
[1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, dist/build/System/Random/TF/Gen.o, dist/build/System/Random/TF/Gen.dyn_o )
[2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o, dist/build/System/Random/TF/Init.dyn_o )
src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations]
In the use of `bitSize'
(imported from Data.Bits, but defined in GHC.Bits):
Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
|
94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented"
| ^^^^^^^
[3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, dist/build/System/Random/TF.o, dist/build/System/Random/TF.dyn_o )
[4 of 4] Compiling System.Random.TF.Instances ( src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o, dist/build/System/Random/TF/Instances.dyn_o )
running tests
Package has no test suites.
haddockPhase
Preprocessing library for tf-random-0.5..
Running Haddock on library for tf-random-0.5..
Warning: --source-* options are ignored when --hyperlinked-source is enabled.
100% ( 4 / 4) in 'System.Random.TF.Gen'
83% ( 5 / 6) in 'System.Random.TF.Init'
Missing documentation for:
Module header
src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations]
In the use of `bitSize'
(imported from Data.Bits, but defined in GHC.Bits):
Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
|
94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented"
| ^^^^^^^
100% ( 7 / 7) in 'System.Random.TF'
33% ( 1 / 3) in 'System.Random.TF.Instances'
Missing documentation for:
Random (src/System/Random/TF/Instances.hs:37)
randomEnum (src/System/Random/TF/Instances.hs:205)
haddock: internal error: dist/doc/html/tf-random/haddock-prologue1387-0.txt: hGetContents: invalid argument (invalid byte sequence)
builder for '/nix/store/jcfgav90wdc628xmnwy468dn5p57nj57-tf-random-0.5.drv' failed with exit code 1
```
</details>
## Steps to reproduce
Since this did not happen with GHC 9.2.1's release candidate, I've not investigated if this may have been caused by nixpkgs' build environment. To reproduce:
* Checkout nixpkgs at `a50888dc73b88ab344853c806ab63a3674728fc6`
* Run `nix-build -A haskell.packages.ghc921.tf-random` on `aarch64-linux`
## Expected behavior
Build `tf-random` successfully including its documentation and display no warnings about incorrect enconding.
## Environment
* GHC version used: 9.2.1
Optional:
* Operating System: NixOS
* System Architecture: aarch64-linux9.2.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20529Instances become invisible across a component boundary2022-04-30T21:28:22ZparsonsmattInstances become invisible across a component boundary## Summary
Reproduction repository: https://github.com/parsonsmatt/visibility
It seems like instances which are considered `visible` in the library component are no longer considered visible when reifying them in the `test` component.
...## Summary
Reproduction repository: https://github.com/parsonsmatt/visibility
It seems like instances which are considered `visible` in the library component are no longer considered visible when reifying them in the `test` component.
The example repo essentially defines:
```haskell
module C where
class C a
module A where
import C
data A = A
instance C A
module B where
import C
import A
data B = B A
instance C B
module T where
import C
import B ()
data T = T
instance C T
```
Based on what I've read on visible type class instances, I would expect that `import T()` would bring into visibility the instances for `B` and `A` as well. This is confirmed - in the library, I can write:
```haskell
module Lib where
import C
import T ()
import Language.Haskell.TH
do
instances <- reifyInstances ''C [VarP (mkName "a")]
print instances
```
and it prints out instance declarations matching `A`, `B`, and `T`.
However, if I run the same code in the *test suite* for this package, then it only shows the instance `C T` - it only shows an instance if it was defined *in the module* that is being imported, not all the transitively imported instances.
## Steps to reproduce
Reproduction repository: https://github.com/parsonsmatt/visibility
`stack build` or `cabal build` should both work. I've tested with GHC 8.10.3, 8.10.7, and 9.0.1.
## Expected behavior
I would expect the instances to be visible just the same in a test-suite or library component.
## Environment
* GHC version used: 8.10.3, 8.10.7, 9.0.1
Optional:
* Operating System: UBuntu
* System Architecture: x86parsonsmattparsonsmatthttps://gitlab.haskell.org/ghc/ghc/-/issues/20464TSAN failures in exitTicker2021-10-05T14:47:08ZBen GamariTSAN failures in exitTickerCurrently the non-threaded RTS produces spurious ThreadSanitizer failures of the form:
```
WARNING: ThreadSanitizer: data race (pid=118233)
Write of size 1 at 0x7f66710635f0 by main thread:
#0 exitTicker rts/posix/ticker/Pthread.c:...Currently the non-threaded RTS produces spurious ThreadSanitizer failures of the form:
```
WARNING: ThreadSanitizer: data race (pid=118233)
Write of size 1 at 0x7f66710635f0 by main thread:
#0 exitTicker rts/posix/ticker/Pthread.c:246 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000007ffc8)
#1 exitTimer rts/Timer.c:209 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000005b4f7)
#2 hs_exit_ rts/RtsStartup.c:478 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000004ccb0)
#3 shutdownHaskellAndExit rts/RtsStartup.c:640 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000004d375)
#4 hs_main rts/RtsMain.c:99 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000004c259)
#5 main <null> (ghc-pkg-9.3.20211002+0x00000047a574)
Previous read of size 1 at 0x7f66710635f0 by thread T1:
#0 itimer_thread_func rts/posix/ticker/Pthread.c:128 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000007fb83)
#1 <null> <null> (libtsan.so.0+0x000000024459)
Location is global 'exited' of size 1 at 0x7f66710635f0 (libHSrts-1.0.2-ghc9.3.20211002.so+0x0000000b35f0)
Thread T1 'ghc_ticker' (tid=118235, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027e9d)
#1 initTicker rts/posix/ticker/Pthread.c:202 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000007fe1b)
#2 initTimer rts/Timer.c:180 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000005b0fa)
#3 hs_init_ghc rts/RtsStartup.c:295 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000004cf98)
#4 hs_main rts/RtsMain.c:57 (libHSrts-1.0.2-ghc9.3.20211002.so+0x00000004c1eb)
#5 main <null> (ghc-pkg-9.3.20211002+0x00000047a574)
SUMMARY: ThreadSanitizer: data race rts/posix/ticker/Pthread.c:246 in exitTicker
```
This is because the non-threaded RTS compiles out all of the barrier and atomic operations defined in `rts/include/stg/SMP.h`. Given that the non-threaded RTS is now no longer single-threaded (as it may use the pthread ticker implementation) we should probably compile at least some of these as their threaded implementations.https://gitlab.haskell.org/ghc/ghc/-/issues/20451Ticky's ticker registration is racy2022-01-05T09:54:13ZBen GamariTicky's ticker registration is racyThe code generated for registration of ticky-ticky counters is currently racy. Specifically, `GHC.StgToCmm.Ticky.registerTickyCtr` adds its ticker to the `ticky_entry_ctrs` linked-list by performing a read-modify-write, which may race wi...The code generated for registration of ticky-ticky counters is currently racy. Specifically, `GHC.StgToCmm.Ticky.registerTickyCtr` adds its ticker to the `ticky_entry_ctrs` linked-list by performing a read-modify-write, which may race with other threads when compiling threaded code. This really ought to rather be an atomic exchange.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20425complex number function errors (all platforms)2022-02-24T09:26:29Zdavjamcomplex number function errors (all platforms)## Summary
Several mathematical functions (e.g. sqrt) give incorrect values for some complex numbers.
## Steps to reproduce
Evaluate the following in GHCi:
````
> :m +Data.Complex
> sqrt $ (-4) :+ (-0)
0.0 :+ 2.0
````
## Expected be...## Summary
Several mathematical functions (e.g. sqrt) give incorrect values for some complex numbers.
## Steps to reproduce
Evaluate the following in GHCi:
````
> :m +Data.Complex
> sqrt $ (-4) :+ (-0)
0.0 :+ 2.0
````
## Expected behavior
````
> sqrt $ (-4) :+ (-0)
0.0 :+ (-2.0)
````
## Environment
* GHC version used: 8.10.7
Optional:
* Operating System: Windows and Linux
* System Architecture:
The above is one example but there are several more errors. I've coded some fixes [here](https://github.com/davjam/HaskellNumericsTestsFixes/blob/main/MyComplex.hs), though these are work in progress.
The github repo also includes some tests (and I'm trying to develop more and may uncover additional issues). I'd like to include a fuller set of tests in GHC.
(I've also just raised #20424 for related issues on real numbers in Windows. Some of the fixes for complex numbers depend on these working correctly).9.4.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20424real number floating point function errors (Windows only)2023-10-27T20:01:23Zdavjamreal number floating point function errors (Windows only)## Summary
Several mathematical functions (asinh, etc) on Double and Float give incorrect values (in Windows only).
## Steps to reproduce
Evaluate the following in GHCi on Windows:
````
> asinh 0
-0.0
> atanh (-0)
0.0
> asinh 1e300
N...## Summary
Several mathematical functions (asinh, etc) on Double and Float give incorrect values (in Windows only).
## Steps to reproduce
Evaluate the following in GHCi on Windows:
````
> asinh 0
-0.0
> atanh (-0)
0.0
> asinh 1e300
NaN
````
## Expected behavior
````
> asinh 0
0.0
> atanh (-0)
-0.0
> asinh 1e300
691.4686750787736
````
(This is correct, and what you get in Linux).
## Environment
* GHC version used: 8.10.7
Optional:
* Operating System: Windows
* System Architecture:
The third example here is the cause of issue #15670.
The cause seems to be errors in the coding of the functions in mingw-w64. I've created/updated bugs [#515](https://sourceforge.net/p/mingw-w64/bugs/515/) and [bug #916](https://sourceforge.net/p/mingw-w64/bugs/916/).
I've coded some fixes [here](https://github.com/davjam/HaskellNumericsTestsFixes/blob/main/MyFloatC.c).
The github repo also includes some tests (and I'm trying to develop more and may uncover additional issues). I'd like to include a fuller set of tests in both GHC and mingw-w64 (if it has CI testing).
The repo also has tests and fixes for complex number problems (that I'll raise as a separate issue since the fixes are in the GHC code).https://gitlab.haskell.org/ghc/ghc/-/issues/20392Infinite loop for Alternative instance for Maybe2021-09-23T11:17:57ZXwtekInfinite loop for Alternative instance for Maybe## Summary
The Alternative Instance for Maybe currently uses the default method provided by Alternative class, that currently does an infinite loop.
## Steps to reproduce
In ghci, run `some $ Just 5` or `many $ Just 5`. It will run in...## Summary
The Alternative Instance for Maybe currently uses the default method provided by Alternative class, that currently does an infinite loop.
## Steps to reproduce
In ghci, run `some $ Just 5` or `many $ Just 5`. It will run into infinite loop without outputting anything.
## Expected behavior
`some $ Just 5` and `many $ Just 5` should both return the same output as `Just $ repeat 5`
Using the property of some and many, we get:
`some v = (:) <$> v <*> many v`
for v = Just a, we get
`some (Just a) = (:) <$> (Just a) <*> many (Just a)`
Plugging in another property `many v = some v <|> pure []` gets us
`some (Just a) = (:) <$> (Just a) <*> (some (Just a) <|> pure [])`
If, some (Just a) return Nothing, then
`some (Just a) = (:) <$> (Just a) <*> (pure [])`
`some (Just a) = Just [a]`
a contradiction, so some (Just a) must return a Just
`some (Just a) = (:) <$> (Just a) <*> some (Just a)`
`some (Just a) = Just (a: (fromJust $ some (Just a)))`
`some (Just a) = Just (a: (fromJust $ Just (a: (fromJust $ ...))))`
`some (Just a) = Just (a: (a: ...))`
`some (Just a) = Just $ repeat a`
Similarly, for many
`many v = some v <|> pure []`
`many v = (Just $ repeat a) <|> pure []`
`many v = (Just $ repeat a)`
## Environment
* GHC version used: 9.0.1
* Operating System: Ubuntu 20.04
* System Architecture: x64Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/20371Serious Data.Data dataTypeName breakage2021-12-17T14:14:08ZDavid FeuerSerious Data.Data dataTypeName breakage## Summary
Under GHC 8.0.2 and earlier, `Data.Data.dataTypeName` behaved as documented:
```haskell
Data.Data> dataTypeName (dataTypeOf (Just ""))
"Prelude.Maybe"
```
Under GHC 8.2.2 and 9.0.1 (and presumably the versions in between),
...## Summary
Under GHC 8.0.2 and earlier, `Data.Data.dataTypeName` behaved as documented:
```haskell
Data.Data> dataTypeName (dataTypeOf (Just ""))
"Prelude.Maybe"
```
Under GHC 8.2.2 and 9.0.1 (and presumably the versions in between),
the module name is omitted:
```haskell
Data.Data> dataTypeName (dataTypeOf (Just ""))
"Maybe"
```
Whoops!
## Environment
* GHC version used: 8.2.2, 9.0.1
Optional:
* Operating System:
* System Architecture:Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/20338GHC.ByteOrder is broken2021-09-09T03:50:31ZAlexey KuleshevichGHC.ByteOrder is broken`GHC.ByteOrder.targetByteOrder` does not report endianness correctly.
Here is how to reproduce:
```haskell
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE CPP #-}
import Data.ByteString.Short.Internal
import GHC...`GHC.ByteOrder.targetByteOrder` does not report endianness correctly.
Here is how to reproduce:
```haskell
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE CPP #-}
import Data.ByteString.Short.Internal
import GHC.ByteOrder
import GHC.Exts
import GHC.IO
#include "MachDeps.h"
data MBA = MBA (MutableByteArray# RealWorld)
homeEndian :: ByteOrder
#ifdef WORDS_BIGENDIAN
homeEndian = BigEndian
#else
homeEndian = LittleEndian
#endif
makeSBS :: IO ShortByteString
makeSBS = do
MBA mba# <-
IO $ \s# ->
case newByteArray# 16# s# of
(# s'#, mba# #) -> (# s'#, MBA mba# #)
IO $ \s# -> (# writeWord64Array# mba# 0# 0x6162636465666768## s#, () #)
IO $ \s# -> (# writeWord64Array# mba# 1# 0x4142434445464748## s#, () #)
IO $ \s# ->
case unsafeFreezeByteArray# mba# s# of
(# s'#, ba# #) -> (# s'#, SBS ba# #)
main :: IO ()
main = do
putStrLn $ "GHC.ByteOrder.targetByteOrder: " ++ show targetByteOrder
putStrLn $ "homeEndian: " ++ show homeEndian
makeSBS >>= print
```
Running this on your regular little endian Intel CPU will produce expected output:
```shell
$ ghc endian.hs -fforce-recomp && ./endian
[1 of 1] Compiling Main ( endian.hs, endian.o )
Linking endian ...
GHC.ByteOrder.targetByteOrder: LittleEndian
homeEndian: LittleEndian
"hgfedcbaHGFEDCBA"
```
However when run on a big endian machine we get:
```shell
root@24bf49042aa4:/# ghc endian.hs -fforce-recomp && ./endian
[1 of 1] Compiling Main ( endian.hs, endian.o )
Linking endian ...
GHC.ByteOrder.targetByteOrder: LittleEndian
homeEndian: BigEndian
"abcdefghABCDEFGH"
```
As you can see from the output of `homeEndian` and the actual byte order in `ShortByteString` the endianness is indeed big endian as expected and `targetByteOrder` reports it incorrectly.
`ghc-byteorder` package works fine because it does the right thing and imports: [`<ghcautoconf.h>`](https://github.com/haskell-hvr/ghc-byteorder/blob/46e84c74ceed19e64023a32012be55d34e545194/src/GHC/ByteOrder.hs#L16-L17)
```haskell
-- Required for WORDS_BIGENDIAN
#include <ghcautoconf.h>
```
which I assume was forgotten when migrated to GHC codebase.
Adding this line to `GHC.ByteOrder` should do a trick:
```haskell
#include "MachDeps.h"
```
In order to debug and replicate this problem I used this project: https://github.com/multiarch/qemu-user-static#getting-started that was suggested to me by Leonhard Markert:
```shell
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker run --rm -it s390x/ubuntu bash
root@24bf49042aa4:/# apt update && apt install ghc
```8.10.1