GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-03-22T15:41:29Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/21240haddock: ASSERTION FAILED: file rts/Stats.c, line 1413 , with --flavour=perf+...2022-03-22T15:41:29Zjwaldmannhaddock: ASSERTION FAILED: file rts/Stats.c, line 1413 , with --flavour=perf+ticky_ghcWhen I build like this
```
time ./hadrian/build -o_build_ticky -j binary-dist --flavour=perf+ticky_ghc
real 52m28.764s ...When I build like this
```
time ./hadrian/build -o_build_ticky -j binary-dist --flavour=perf+ticky_ghc
real 52m28.764s
user 211m32.191s
sys 10m13.623s
```
it's dog slow (with most of the extra time spent in haddock?) and I get lots of
```
...
haddock: ASSERTION FAILED: file rts/Stats.c, line 1413
haddock: ASSERTION FAILED: file rts/Stats.c, line 1413
| Create directory _build_ticky/stage1/haddock-timing-files | Create directory _build_ticky/stage1/haddock-timing-files
| Run Haddock BuildPackage: _build_ticky/stage1/libraries/libiserv/build/GHCi/Utils.hs (and 1 more) => _build_ticky/docs/html/libr
aries/libiserv/libiserv.haddock
| Run Haddock BuildPackage: compiler/GHC.hs (and 616 more) => _build_ticky/docs/html/libraries/ghc/ghc.haddock
| Create directory _build_ticky/stage1/haddock-timing-files
| Run Haddock BuildPackage: libraries/Cabal/Cabal-syntax/src/Distribution/Backpack.hs (and 136 more) => _build_ticky/docs/html/lib
raries/Cabal-syntax/Cabal-syntax.haddock
haddock: ASSERTION FAILED: file rts/Stats.c, line 1413
...
```
For reference, a normal build of master:
```
time ./hadrian/build -j binary-dist
real 25m44.764s
user 120m18.564s
sys 8m44.086s
```
(the last 5 min of both are spent in `xz` #20614 but that does not matter here)https://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/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/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/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/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/20317Odd interaction between unsafePerformIO and threadDelay2024-02-27T13:58:43ZDavid FeuerOdd interaction between unsafePerformIO and threadDelay## Summary
`threadDelay` doesn't seem to resume properly after an exception in an `unsafePerformIO` context.
## Steps to reproduce
```
ghci -threaded
> import Control.Concurrent
> import System.IO.Unsafe
> import Control.Exception
> ...## Summary
`threadDelay` doesn't seem to resume properly after an exception in an `unsafePerformIO` context.
## Steps to reproduce
```
ghci -threaded
> import Control.Concurrent
> import System.IO.Unsafe
> import Control.Exception
> let okay = unsafePerformIO (evaluate (sum [1..10^7]) *> putStrLn "Hi there.")
> okay
-- Hit Ctrl-C
-- See "^CInterrupted."
> okay
-- After a few seconds, it prints "Hi there." and then "()".
> let oops = unsafePerformIO (threadDelay (10^7) *> putStrLn "Hi there.")
> oops
-- Hit Ctrl-C
-- See "^CInterrupted."
> oops
-- See "^CInterrupted."
```
## Expected behavior
I would expect the `threadDelay` call to resume, and to eventually see "Hi there." and the `()` return value.
## Environment
* GHC version used: 9.0.1
Optional:
* Operating System: Linux (OpenSUSE)
* System Architecture: x86_64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/19935getExecutablePath returns ld loader path2021-06-04T09:44:29ZDaneel S. YaitskovgetExecutablePath returns ld loader pathif Haskell program is launched through ld linkder then
System.Environment.getExecutablePath returns path to the linker not to the program, meanwhile getArgs works correctly and first argument is not a path to the Haskell program, the la...if Haskell program is launched through ld linkder then
System.Environment.getExecutablePath returns path to the linker not to the program, meanwhile getArgs works correctly and first argument is not a path to the Haskell program, the last fact makes hard to implement workaround.
```
module Main where
import System.Environment
main :: IO ()
main = do
p <- getExecutablePath
print p
x <- getArgs
print x
```
```
ghc --make -o print-args Main.hs
```
```
readelf -a print-args | grep Requesting
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
/lib64/ld-linux-x86-64.so.2 $PWD/print-args a b c
"/usr/lib/x86_64-linux-gnu/ld-2.28.so"
["a","b","c"]
```
```
ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.4
uname -a
Linux diehard 5.9.13 #1 SMP Wed Dec 9 14:12:51 MSK 2020 x86_64 GNU/Linux
```
workaround:
```
getFullProgName :: IO String
getFullProgName =
alloca $ \ p_argc ->
alloca $ \ p_argv -> do
getFullProgArgv p_argc p_argv
peek p_argv >>= peek >>= peekCString
foreign import ccall unsafe "getFullProgArgv"
getFullProgArgv :: Ptr CInt -> Ptr (Ptr CString) -> IO ()
main = getFullProgName >>= putStrLn
```https://gitlab.haskell.org/ghc/ghc/-/issues/19917Unsound optimization with `error`, introduced in GHC 8.22024-02-22T11:21:40ZAndreas AbelUnsound optimization with `error`, introduced in GHC 8.2We discovered an unsound optimization (see https://github.com/agda/agda-stdlib/pull/1512) in GHC starting with 8.2. I managed to shrink it down to the following code:
```haskell
-- Unsound compiler optimization in presence of @error@.
...We discovered an unsound optimization (see https://github.com/agda/agda-stdlib/pull/1512) in GHC starting with 8.2. I managed to shrink it down to the following code:
```haskell
-- Unsound compiler optimization in presence of @error@.
foo :: String -> String
foo d1@(_:_)
| not (all (== '-') d1)
, last d1 == '\r'
= error "OK1"
foo _ = error "OK2"
main = putStr $ foo "Hello, world!"
```
With -O0, or until GHC 8.0.2, this outputs
```
<main>: OK2
CallStack (from HasCallStack):
error, called at <loc> in main:Main
```
With -O1 or -O2 and GHC 8.2 - 9.0.1, (I tested from 8.2.2), this gives:
```
Prelude.last: empty list
```https://gitlab.haskell.org/ghc/ghc/-/issues/19841Debug.Trace.trace optimized away when throwing exceptions, starting with GHC 8.82023-07-20T07:17:29ZAndreas AbelDebug.Trace.trace optimized away when throwing exceptions, starting with GHC 8.8## Summary
`Debug.Trace.trace` messages printed with `-O0` are optimized away (e.g. with `-O1`) in the presence of `Control.Exception.throw`, starting with GHC 8.8.
## Steps to reproduce
Compile and run this with either `-O0` or `-O1`...## Summary
`Debug.Trace.trace` messages printed with `-O0` are optimized away (e.g. with `-O1`) in the presence of `Control.Exception.throw`, starting with GHC 8.8.
## Steps to reproduce
Compile and run this with either `-O0` or `-O1`:
```haskell
import Control.Exception
import Debug.Trace
data MyException = MyException deriving Show
instance Exception MyException
main :: IO ()
main = handle (\ MyException -> putStrLn "Exception") $ do
trace "Debugging" 5
`seq` throw MyException
`seq` putStrLn "Survived Exception"
```
## Expected behavior
I expect the output
```
Debugging
Exception
```
which is delivered with `-O0` and, up to GHC 8.6, also with `-O1`.
Starting with GHC 8.8 at `-O1`, it prints only
```
Exception
```
## Further research
My mental model for `Debug.Trace.trace :: String -> a -> a` is one of
```haskell
trace msg a = unsafePerformIO (putStrLn msg) `seq` a
trace msg a = unsafePerformIO $ do
putStrLn msg
return a
```
Both of these actually work, meaning that the debug message is **not** optimized away for these simple implementations.
Trivium: I found this bug (as I would call it) when researching https://github.com/agda/agda/issues/5379.
## Environment
* GHC versions used: 8.0.2, 8.2.2, 8.4.4, 8.6.4, 8.8.4, 8.10.4, 9.0.1
Optional:
* Operating System: macOS Mojave 10.14.6
* System Architecture: Macky McMacFacehttps://gitlab.haskell.org/ghc/ghc/-/issues/19724Non-reproducible failure in RestartEventLogging test in `threaded1` way.2021-04-22T01:01:31ZvdukhovniNon-reproducible failure in RestartEventLogging test in `threaded1` way.## Summary
Running `validate` by hand the test typically succeeds, but on one run I got:
```
...
--- tests/rts/RestartEventLogging.run/RestartEventLogging.stdout.normalised 2021-04-20 21:29:06.924934000 -0400
+++ tests/rts/RestartEventL...## Summary
Running `validate` by hand the test typically succeeds, but on one run I got:
```
...
--- tests/rts/RestartEventLogging.run/RestartEventLogging.stdout.normalised 2021-04-20 21:29:06.924934000 -0400
+++ tests/rts/RestartEventLogging.run/RestartEventLogging.run.stdout.normalised 2021-04-20 21:29:06.925062000 -0400
@@ -8,6 +8,11 @@
stop
init
Event log started with EVENT_HEADER_BEGIN
+ERROR: event does not start with EVENT_HEADER_BEGIN
+0x0 != 0x68
+0x12 != 0x64
+0x0 != 0x72
+0x0 != 0x62
stop
init
Event log started with EVENT_HEADER_BEGIN
...
tests/rts/RestartEventLogging.run RestartEventLogging [bad stdout] (threaded1)
```
The expected value is:
```
includes/rts/EventLogFormat.h:#define EVENT_HEADER_BEGIN 0x68647262 /* 'h' 'd' 'r' 'b' */
```
but we got '\0\x12\0\0'.
## Steps to reproduce
Not easily reproducible, could even be a hardware glitch, though that seems unlikely...
## Expected behavior
The test should ideally pass consistently
## Environment
* GHC version used: commit 4cfb6b89479d873f1091dce59f7fbed635d37d6a (HEAD -> freebsd-tlsgd, v/freebsd-tlsgd) of MR !5561. The merge-base with head is: commit 0619fb0fb14a98f04aac5f031f6566419fd27495 (origin/master, origin/HEAD, master)
Optional:
* Operating System: FreeBSD 12.2
* System Architecture: X86_64https://gitlab.haskell.org/ghc/ghc/-/issues/19369Data.Complex doesn't consistently distinguish -0.02022-03-14T08:22:59ZJKTKopsData.Complex doesn't consistently distinguish -0.0## Summary
This is a bit of a nitpick.
I'm implementing a numeric system for an interpreter that supports complex numbers. I want to piggyback off of Data.Complex as much as possible since it would be pretty silly to just duplicate all...## Summary
This is a bit of a nitpick.
I'm implementing a numeric system for an interpreter that supports complex numbers. I want to piggyback off of Data.Complex as much as possible since it would be pretty silly to just duplicate all of the code that already exists.
Normal Haskell Doubles are IEEE doubles, which means there is both a +0.0 and a -0.0. Haskell does (because it would be more effort not to) distinguish between these values in computations, notably `1 / 0.0 = Infinity` but `1 / (-0.0) = -Infinity`. When working with `Complex Double`, this means that the difference between 0.0 and -0.0 is observable. However the implementation of phase has a short-circuit for when the argument is equal to 0 so that the phase is always 0.
As a result, since many `Floating` operations are defined in terms of `log`, which is defined in terms of `phase`, the results are incosistent with other languages at -0. Other languages (including, hopefully, mine) which distinguish 0.0 and -0.0 give `log 0.0 = -Infinity` but `log (-0.0) = -Infinity + pi*i`. Using Data.Complex, both are always `-Infinity`.
Note that the standard example of log's branch cut, `log (-1-0i)` behaves correctly, giving `0 :+ (-pi)`.
## Steps to reproduce
Apply `phase ((-0.0) :+ 0)`.
## Expected behavior
Result is `pi`.
## Environment
* base-4.14.0.0https://gitlab.haskell.org/ghc/ghc/-/issues/19053Strange behavior when using -O2020-12-15T15:54:22ZArthur KhashaevStrange behavior when using -O## Summary
I've encountered a strange behavior using `ghc -O` on the program with `Prelude.last`, `Data.List.group`, `System.Exit`, and `IO` effects.
## Steps to reproduce
```hs
import Data.List (group)
import System.Exit (exitFailure...## Summary
I've encountered a strange behavior using `ghc -O` on the program with `Prelude.last`, `Data.List.group`, `System.Exit`, and `IO` effects.
## Steps to reproduce
```hs
import Data.List (group)
import System.Exit (exitFailure, exitSuccess)
main :: IO ()
main = do
_ <- getContents
if last (group "a") == "a" then exitSuccess else exitFailure
```
```
ghc -O snippet.hs -o snippet && ./snippet
```
## Actual behaviour
```
snippet: Prelude.last: empty list
```
Even strange, this can be fixed in one of the following ways:
- Compiling without `-O`.
- Removing `_ <- getContents`.
- Reducing `(group "a")` to `["a"]` or `last (group "a")` to `"a"`.
## Expected behavior
I expect successful exit without `Prelude.last: empty list` error.
## Environment
* GHC version used: `The Glorious Glasgow Haskell Compilation System, version 8.6.5` from deb package `ghc/focal 8.8.1+dfsg1+is+8.6.5+dfsg1-3 amd64`.
Optional:
* Operating System:
`Linux host 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux`
* System Architecture:
`x86_64`https://gitlab.haskell.org/ghc/ghc/-/issues/18876T13330 fails sporatically on Windows2020-10-22T13:47:37ZBen GamariT13330 fails sporatically on Windows`T13330` appears to fails every once in a while on Windows:
```patch
--- "C:/GitLabRunner/builds/2WeHDSFP/0/ghc/ghc/tmp/ghctest-d__9bkso/test spaces/testsuite/tests/concurrent/should_run/T13330.run/T13330.stderr.normalised" 2020-10-21 ...`T13330` appears to fails every once in a while on Windows:
```patch
--- "C:/GitLabRunner/builds/2WeHDSFP/0/ghc/ghc/tmp/ghctest-d__9bkso/test spaces/testsuite/tests/concurrent/should_run/T13330.run/T13330.stderr.normalised" 2020-10-21 15:48:19.306187300 +0000
+++ "C:/GitLabRunner/builds/2WeHDSFP/0/ghc/ghc/tmp/ghctest-d__9bkso/test spaces/testsuite/tests/concurrent/should_run/T13330.run/T13330.run.stderr.normalised" 2020-10-21 15:48:19.306187300 +0000
@@ -1,3 +0,0 @@
-T13330: Successful exception
-CallStack (from HasCallStack):
- error, called at T13330.hs:<line>:<column> in <package-id>:Main
```https://gitlab.haskell.org/ghc/ghc/-/issues/18871Fix Alternative instance for IO2021-07-09T19:32:10ZIsaac BergerFix Alternative instance for IO
The Alternative instance for IO is currently defined in GHC.Base, using
```
(<|>) = mplusIO
```
Hunting further, mplusIO is defined in GHC.IO as
```
mplusIO :: IO a -> IO a -> IO a
mplusIO m n = m `catchException` \ (_ :: IOError) -> n...
The Alternative instance for IO is currently defined in GHC.Base, using
```
(<|>) = mplusIO
```
Hunting further, mplusIO is defined in GHC.IO as
```
mplusIO :: IO a -> IO a -> IO a
mplusIO m n = m `catchException` \ (_ :: IOError) -> n
```
## Why this is (possibly) wrong
Quoting documentation in Control.Exception
> Applying mask to an exception handler
>
> There's an implied mask around every exception handler in a call to one of the catch family of functions. This is because that is what you want most of the time - it eliminates a common race condition in starting an exception handler, because there may be no exception handler on the stack to handle another exception if one arrives immediately. If asynchronous exceptions are masked on entering the handler, though, we have time to install a new exception handler before being interrupted. If this weren't the default, one would have to write something like
>
> mask $ \restore ->
> catch (restore (...))
> (\e -> handler)
> If you need to unmask asynchronous exceptions again in the exception handler, restore can be used there too.
>
> Note that try and friends do not have a similar default, because there is no exception handler in this case. Don't use try for recovering from an asynchronous exception.
Being that `mplusIO` only catches exceptions of type `IOError`, it is not suited for cleanup work. It is more likely useful for running a fallback action should the first one fail. In this case, one would not want to prevent asynchronous exceptions from being able to interrupt the application in the alternative branch.
So I would suggest a better implementation for `mplusIO` should be based on `try` rather than `catch`
Something like:
```
mplusIO :: IO a -> IO a -> IO a
mplusIO m n = do
res <- catchException (m >>= \ v -> return (Right v)) (\e -> return (Left e))
case res of
Right a -> return a
Left (e :: IOError) -> n
```https://gitlab.haskell.org/ghc/ghc/-/issues/18868Reversed profile stack2020-10-20T14:43:34ZDouglas RAILLARDReversed profile stack## Summary
Here are two extracts from the same profiling report file:
```
parseIntegral Trace.Internal src/Trace/Internal.hs:(101,56)-(104,61) 622 3871885 18.7 1...## Summary
Here are two extracts from the same profiling report file:
```
parseIntegral Trace.Internal src/Trace/Internal.hs:(101,56)-(104,61) 622 3871885 18.7 16.8 80.8 71.1 4084 3057274056
eventParser Trace src/Trace.hs:(343,87)-(374,9) 623 1930555 4.3 5.7 60.5 54.3 947 1027402080
parseFieldKind Trace src/Trace.hs:(454,9)-(468,48) 636 1936408 0.8 0.6 0.8 0.6 172 107905344
```
And
```
eventParser Trace src/Trace.hs:(343,87)-(374,9) 626 0 0.0 0.0 0.0 0.0 0 0
fieldParsers Trace src/Trace.hs:347:51-128 628 16 0.0 0.0 0.0 0.0 0 26880
parseFieldKind Trace src/Trace.hs:(454,9)-(468,48) 630 98 0.0 0.0 0.0 0.0 0 3472
parseIntegral Trace.Internal src/Trace/Internal.hs:(101,56)-(104,61) 635 59 0.0 0.0 0.0 0.0 0 0
```
The 2nd one shows the stack in the expected order. `parseIntegral` is a simple routine that does not make any direct or indirect call to `eventParser`. The only way I can see it could end up running `eventParser` code is through a thunk, but the documentation[1] explicitly mentions this case as being handled. Upon forcing, the stack attached to the thunk should be restored and the current cost center should therefore change to the one that created the thunk, not the one forcing it.
[1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#rules-for-attributing-costs
## Steps to reproduce
Compile with `-prof` and `-fno-prof-auto`, `-fno-prof-cafs` (this is done via stack though, so other options might be included by it).
## Expected behavior
My understanding is that the first stack snippet should not exist in the profile report.
## Environment
* GHC version used: 8.10.2
Optional:
* Operating System: Archlinux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/18829Strange behavior when optimization is turned on, with GHC >= 8.2.22020-11-09T15:13:23ZVanessa McHaleStrange behavior when optimization is turned on, with GHC >= 8.2.2## Summary
Test suite produces strange errors/results when run with optimizations on (for later GHCs). Also, results vary from run to run.
## Steps to reproduce
Download and install [J](https://code.jsoftware.com/wiki/System/Installat...## Summary
Test suite produces strange errors/results when run with optimizations on (for later GHCs). Also, results vary from run to run.
## Steps to reproduce
Download and install [J](https://code.jsoftware.com/wiki/System/Installation/J901/Debian).
```
git clone https://github.com/vmchale/j-hs.git
cd j-hs/
cabal test -w ghc-8.10.2
cabal test -w ghc-8.0.2
cabal test -w ghc-8.10.2 -O0
```
(revision `475755ca3d3dc5ce0557e42ef0df321457b8ebac`?)
Then this gives:
```
J dl
Performs calculation and has sensible output: OK
Reads back type in the environment: OK
Reads a string: OK
Sends an array to J: OK
Uses J to perform a complex calculation: OK
Writes strigns to J values: OK
Uses J for something Haskell would have a hard time with: j-test: internal error: index out of bounds
CallStack (from HasCallStack):
error, called at ./Test/Tasty/Ingredients/ConsoleReporter.hs:178:20 in tasty-1.3.1-268a33715c1414c235611995fa9c09de6e68f7c1c3aa3455f08d0451da953e2d:Test.Tasty.Ingredients.ConsoleReporter
Test suite j-test: FAIL
```
for GHC 8.10.2, then works fine with GHC 8.0.2 or when optimization is set to `-O0`.
Unfortunately I can't get a stack trace since compiling with `--enable-profiling` gives yet another failure mode, viz.
```
J dl
Performs calculation and has sensible output: OK
Reads back type in the environment: OK
Reads a string: OK
Sends an array to J: OK
Uses J to perform a complex calculation: OK
Writes strigns to J values: OK
Uses J for something Haskell would have a hard time with: OK
All 7 tests passed (0.00s)
Test suite j-test: FAIL
Test suite logged to:
/home/vanessa/programming/haskell/current/j/dist-newstyle/build/x86_64-linux/ghc-8.10.2/j-0.1.0.0/t/j-test/test/j-0.1.0.0-j-test.log
```
...which is puzzling/contradictory!
## Expected behavior
I expect it to pass the test suite or at least for the results to be consistent.
I definitely don't expect to see a tasty bug in the stack trace since I don't think that code is buggy.
## Environment
* GHC version used: 8.10.2, 8.8.4, 8.6.5, 8.4.4, 8.2.2, 8.0.2, 7.10.3
Optional:
* Operating System: Lubuntu 18.04
* System Architecture: x86_64Ben GamariBen Gamari