GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-21T23:01:00Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17694ParallelListComp semantics differs from the documented one2021-12-21T23:01:00ZRoman CheplyakaParallelListComp semantics differs from the documented oneThe desugaring of parallel list comprehensions described [in the manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#parallel-list-comprehensions) appears to state that parallel bars (`|`) have highe...The desugaring of parallel list comprehensions described [in the manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#parallel-list-comprehensions) appears to state that parallel bars (`|`) have higher precedence than what comes after them, but this is not how they work in practice.
## Example 1
``` haskell
{-# LANGUAGE ParallelListComp #-}
main = print
[ (a, b)
| a <- [1 .. 5]
| b <- [1 .. 5]
, b >= 4
]
```
The desugaring implied by the docs is
``` haskell
main = print
[ (a, b)
| (a, b) <- zip [1 .. 5] [1 .. 5]
, b >= 4
]
```
so I'd expect the result to be [(4,4),(5,5)]. Yet the actual result is [(1,4),(2,5)], showing that the comma has higher precedence here.
## Example 2
``` haskell
{-# LANGUAGE ParallelListComp #-}
main = print
[ (a, b)
| a <- [1 .. 5]
| b <- [1 .. 5]
, a >= 4
]
```
Result:
```
parlistcomp.hs:7:5: error:
• Variable not in scope: a :: Integer
• Perhaps you meant ‘a’ (line 5)
|
7 | , a >= 4
| ^
```
Again, this is consistent with the comma binding more tightly than the bar. But also notice that ghc itself is confused about the scoping rules: it says `a` is not in scope, yet suggests `a` as a valid replacement.
## Environment
* GHC version used: 8.6.5, 8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/18269Closure size functions will return incorrect for closures with static links2020-06-02T14:12:21ZÖmer Sinan AğacanClosure size functions will return incorrect for closures with static linksNot sure if this is a bug or not, but here goes.
Closure size functions like `closureSize#` (primop) and `closure_size` (C function) don't take static link fields into account, so they will return incorrect result for top-level construc...Not sure if this is a bug or not, but here goes.
Closure size functions like `closureSize#` (primop) and `closure_size` (C function) don't take static link fields into account, so they will return incorrect result for top-level constructors (e.g. SRTs, or CAFFY constructors).
It seems like the assumption here is they'll always be passed heap-allocated closures, but as far as I can see this fact is not documented, e.g. in `ghc-heap`'s `closureSize`:
```haskell
-- | Get the size of the top-level closure in words.
-- Includes header and payload. Does not follow pointers.
--
-- @since 8.10.1
closureSize :: Box -> Int
closureSize (Box x) = I# (closureSize# x)
```
Note that, confusingly, "top-level" here means that the function does not recursively visit payloads, not that the closure is actually top-level!https://gitlab.haskell.org/ghc/ghc/-/issues/18370`BlockedIndefinitelyOnMVar` is thrown to non-blocked threads2022-09-12T00:31:00ZOle`BlockedIndefinitelyOnMVar` is thrown to non-blocked threads## Summary
`BlockedIndefinitelyOnMVar` is thrown to other threads that weren't blocked.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control...## Summary
`BlockedIndefinitelyOnMVar` is thrown to other threads that weren't blocked.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control.Exception
main :: IO ()
main = do
emptyVar <- newEmptyMVar @()
resultVar <- newEmptyMVar
_ <- forkIO $ do
caught <- try @SomeException (readMVar emptyVar)
putMVar resultVar caught
print ("thread", caught)
result <- readMVar resultVar
print ("main", result)
```
```
$ ghc -Wall -Wextra -threaded Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
("thread",Left thread blocked indefinitely in an MVar operation)
Test: thread blocked indefinitely in an MVar operation
$ ./Test +RTS -N
Test: thread blocked indefinitely in an MVar operation
("thread",Left thread blocked indefinitely in an MVar operation)
```
It appears the main thread is being thrown a `BlockedIndefinitelyOnMVar` as well.
This can be decoupled from the empty MVar read:
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control.Concurrent.STM
import Control.Exception
main :: IO ()
main = do
emptyVar <- newEmptyTMVarIO @()
resultVar <- newEmptyMVar
_ <- forkIO $ do
caught <- try @SomeException (atomically (readTMVar emptyVar))
putMVar resultVar caught
print ("thread", caught)
result <- readMVar resultVar
print ("main", result)
```
```
$ ghc -Wall -Wextra -threaded Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
("thread",Left thread blocked indefinitely in an STM transaction)
Test: thread blocked indefinitely in an MVar operation
$ ./Test +RTS -N
Test: thread blocked indefinitely in an MVar operation
("thread",Left thread blocked indefinitely in an STM transaction)
```
## Expected behavior
I expect both threads to print the result of `try` in unspecified order.
```
λ ./Test +RTS -N
("thread",Left thread blocked indefinitely in an MVar operation)
("main",Left thread blocked indefinitely in an MVar operation)
```
## Environment
* GHC version used:
- 8.10.1
- 8.8.3
Optional:
* Operating System: NixOS, Linux 5.4.31 x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/18418withArgs and withProgName permanently modify argv[0]2020-07-14T14:20:26ZAndreas HerrmannwithArgs and withProgName permanently modify argv[0]## Summary
The functions `withArgs` and `withProgName` are meant to temporarily modify the program arguments, either `argv[1]` and upwards or `argv[0]`. However, they both have the side-effect to permanently modify `argv[0]`.
## Steps ...## Summary
The functions `withArgs` and `withProgName` are meant to temporarily modify the program arguments, either `argv[1]` and upwards or `argv[0]`. However, they both have the side-effect to permanently modify `argv[0]`.
## Steps to reproduce
Consider the following example program (full project attached [ghc_arg0.tgz](/uploads/d2515b74bfbbd1567dd334d1fc7db639/ghc_arg0.tgz)
):
```
module Main where
import Arg0 (getArg0)
import System.Environment (withArgs, withProgName)
main :: IO ()
main = do
before <- getArg0
during <- withProgName "manual" getArg0
-- during <- withArgs [] getArg0
after <- getArg0
putStrLn $ "before " ++ before ++ "\nduring " ++ during ++ "\nafter " ++ after
```
Observe the following behavior
```
$ cabal run
before /home/user/ghc_arg0/dist-newstyle/build/x86_64-linux/ghc-8.10.1/ghc-arg0-0.1.0.0/x/ghc-arg0/build/ghc-arg0/ghc-arg0
during manual
after ghc-arg0
```
I.e. the result of `getArg0` is different before and after `withProgName` (same with `withArgs`).
## Expected behavior
`withProgName` and `withArgs` should fully restore `argv[0]`. I.e. the output above should be
```
before /home/user/ghc_arg0/dist-newstyle/build/x86_64-linux/ghc-8.10.1/ghc-arg0-0.1.0.0/x/ghc-arg0/build/ghc-arg0/ghc-arg0
during manual
after /home/user/ghc_arg0/dist-newstyle/build/x86_64-linux/ghc-8.10.1/ghc-arg0-0.1.0.0/x/ghc-arg0/build/ghc-arg0/ghc-arg0
```
## Environment
* GHC version used: 8.10.1
Optional:
* Operating System: Ubuntu 19.10
* System Architecture: x86_64
## Additional context
As pointed out in https://gitlab.haskell.org/ghc/ghc/-/issues/3199 there is no easy access to `argv[0]` in GHC. The attached example uses a slight variation of `getProgName` that doesn't invoke `basename` on the result. Alternatively, there is https://hackage.haskell.org/package/system-argv0-0.1.1.
The motivating use-case is to determine the path by which the program was invoked, see https://github.com/tweag/rules_haskell/pull/1387 for details. Note, this is not necessarily the same as the result of `getExecutablePath` as that one uses `/proc/self/exe` and resolves symbolic links. The issue was caused by a program calling `getProgName` around an optparse-applicative parser to control the program name in error messages generated by optparse-applicative.https://gitlab.haskell.org/ghc/ghc/-/issues/18444GHC does not respect semantics of bang patterns2023-01-15T10:52:48ZRichard Eisenbergrae@richarde.devGHC does not respect semantics of bang patternsIf I write
```hs
a :: forall a. a -> a
a = let y :: Eq a => a
!y = undefined
in \z -> z
```
and evaluate `a True`, I get `True`. This is surprising -- I expected to see an exception thrown. The problem is that GHC does not ...If I write
```hs
a :: forall a. a -> a
a = let y :: Eq a => a
!y = undefined
in \z -> z
```
and evaluate `a True`, I get `True`. This is surprising -- I expected to see an exception thrown. The problem is that GHC does not instantiate `y` before forcing it. `y` is a function from `Eq a` to `a`, and thus is a value.
Yet https://gitlab.haskell.org/haskell/prime/-/wikis/BangPatterns describes the desugaring of the above to be
```hs
a :: forall a. a -> a
a = let y :: Eq a => a
y = undefined
in y `seq` \z -> z
```
which does not compile, as there is no `Eq a` instance. I think we should stick to the specification here and reject both programs. This means that GHC will struggle to support a strict binding of a polymorphic value, but I think that's appropriate, as I would want users to be careful in this corner and say exactly what they mean, lest they get surprised by GHC's behavior.https://gitlab.haskell.org/ghc/ghc/-/issues/18590GHC.HsToCore.Coverage doesn't take expressions in View Patterns into account2020-09-30T21:48:51ZZubinGHC.HsToCore.Coverage doesn't take expressions in View Patterns into account```haskell
{-# LANGUAGE ViewPatterns #-}
main = do
x <- readLn
let str (if x == 0 then id else const 2 -> y) = show y
putStrLn (str 1)
{-
$ hpc report Main
100% expressions used (7/7)
100% boolean coverage (0/0)
10...```haskell
{-# LANGUAGE ViewPatterns #-}
main = do
x <- readLn
let str (if x == 0 then id else const 2 -> y) = show y
putStrLn (str 1)
{-
$ hpc report Main
100% expressions used (7/7)
100% boolean coverage (0/0)
100% guards (0/0)
100% 'if' conditions (0/0)
100% qualifiers (0/0)
100% alternatives used (0/0)
100% local declarations used (1/1)
100% top-level declarations used (1/1)
-}
{-
Changing str to
let str z = let y = (if x == 0 then id else const 2) z in show y
results in
$ hpc report Main
86% expressions used (13/15)
0% boolean coverage (0/1)
100% guards (0/0)
0% 'if' conditions (0/1), 1 always True
100% qualifiers (0/0)
50% alternatives used (1/2)
100% local declarations used (2/2)
100% top-level declarations used (1/1)
-}
```
Specifically, the problem is in `addTickMatch` and `addTickCmdMatch`. They are defined like so:
```haskell
addTickMatch isOneOfMany isLambda match@(Match { m_pats = pats
, m_grhss = gRHSs }) =
bindLocals (collectPatsBinders pats) $ do
gRHSs' <- addTickGRHSs isOneOfMany isLambda gRHSs
return $ match { m_grhss = gRHSs' }
```
They return the `pats` as they occurred in the original expression and don't add ticks in the expressions inside them.https://gitlab.haskell.org/ghc/ghc/-/issues/18619Data.Bits.shiftL should generate overflow exception for Integer operand2021-01-24T21:07:13ZSergei TrofimovichData.Bits.shiftL should generate overflow exception for Integer operand## Summary
`Data.Bits.shiftL` doc says `shiftL` should never be called with negative value. `Int` instance returns an overflow exception, but `Integer` returns something reasonable. It's confusing to see behaviour change by slightly cha...## Summary
`Data.Bits.shiftL` doc says `shiftL` should never be called with negative value. `Int` instance returns an overflow exception, but `Integer` returns something reasonable. It's confusing to see behaviour change by slightly changing the type of a program:
```
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Prelude> Data.Bits.shiftL (1 :: Integer) ((-1) :: Int)
0
Prelude> Data.Bits.shiftL (1 :: Int) ((-1) :: Int)
*** Exception: arithmetic overflow
```
Should `Integer` instance also throw an exception?https://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 Gamarihttps://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/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/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/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/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/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/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/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/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/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/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/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 Gamari