GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-01-24T21:07:13Zhttps://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/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/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/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/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/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/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/17451surprising SIGQUIT behavior "This build does not support backtraces."2019-11-08T21:51:17Zjoeyhsurprising SIGQUIT behavior "This build does not support backtraces."## Summary
I hit ctrl-\ to send a hard SIGQUIT to my program, which I knew does not install a handler for that and wanted to exit immediately (w/o running its usual SIGINT handler), and was surprised to see "This build does not support ...## Summary
I hit ctrl-\ to send a hard SIGQUIT to my program, which I knew does not install a handler for that and wanted to exit immediately (w/o running its usual SIGINT handler), and was surprised to see "This build does not support backtraces." and the program contining to run.
I happened to have run my program from a shell script, and the SIGQUIT terminated the shell that had run it, which left my program running in a kind of backgrounded state where it contended with my interactive shell. And my program happened to have run another program and was itself surprised to see that program, which also received the SIGQUIT, exiting unexpectedly with an unusual exit code.
I think there's a reasonable expectation that SIGQUIT leads to a prompt terminatation of the program, with or without a core dump or something associated with a core dump such as a backtrace. Leaving the program running and printing out an unusual (and untranslated BTW) message to stderr has a high potential to exercise unusual code paths. Some programs may have a good reason to not exit on SIGQUIT, but then the program has to be designed to work that way. ghc is assuming any program will work acceptably if it keeps running after a SIGQUIT, and that is not the case.
In Signals.c, I'd suggest only installing the SIGQUIT handler #if USE_LIBDW.
Or, if it's important to communicate the the user that it was not built with backtrace support, it could display the message and then exit.
(It looks like the program might keep running when built with LIBDW too, and maybe that's intentional in order to see repeated backtraces, but I think my reasoning on prompt termination could also apply there.)
## Steps to reproduce
Start a long-running git-annex operation, like a "git annex add" in a directory with ots of files, and send it a SIGQUIT.
## Expected behavior
Terminate immediately.
## Environment
* GHC version used: 8.6.5 from Debian
Optional:
* Operating System: Linux
* System Architecture: 864-64https://gitlab.haskell.org/ghc/ghc/-/issues/17285Program hangs on ppc64el2019-11-03T11:10:47ZIlias TsitsimpisProgram hangs on ppc64el## Summary
The testsuite for terminal-progress-bar fails (hangs) on both ppc64el and ppc64 (see build logs [here](https://buildd.debian.org/status/package.php?p=haskell-terminal-progress-bar&suite=sid)).
## Steps to reproduce
In order...## Summary
The testsuite for terminal-progress-bar fails (hangs) on both ppc64el and ppc64 (see build logs [here](https://buildd.debian.org/status/package.php?p=haskell-terminal-progress-bar&suite=sid)).
## Steps to reproduce
In order to reproduce this, I tried the following on ppc64el:
```bash
$ cabal install terminal-progress-bar==0.4.1
$ cat Progress.hs
module Main where
import Data.Time.Clock
import System.ProgressBar
main = do
print $ renderProgressBar defStyle (Progress 0 1 ()) someTiming
where
someTime :: UTCTime
someTime = UTCTime (toEnum 0) 0
someTiming :: Timing
someTiming = Timing someTime someTime
$ ghc -o progress Progress.hs
$ ./progress
```
This hangs forever, with the process taking 100% CPU.
The interesting part is that if I modify the [ProgressBar.hs](https://github.com/roelvandijk/terminal-progress-bar/blob/master/lib/src/System/ProgressBar.hs) file to contain the above main function, and compile that one, it finishes successfully. This is why I assume this is a GHC bug.
## Environment
* GHC version used: 8.6.5
I tried the same think with v8.4.4 from Debian buster and it run without a problem, so this is a regression.https://gitlab.haskell.org/ghc/ghc/-/issues/17206Unsound optimization with -O in ghc 8.4 and 8.6 when using unsafeCoerce (prod...2019-09-19T13:06:42ZAndreas AbelUnsound optimization with -O in ghc 8.4 and 8.6 when using unsafeCoerce (produced by Agda)## Summary
Unsound optimization of `unsafeCoerce` with `-O` under GHC 8.4 and 8.6.
The following code was shrunk from code generated by the GHC backend of Agda. Agda in essence targets the untyped lambda calculus, thus, uses `unsafeCo...## Summary
Unsound optimization of `unsafeCoerce` with `-O` under GHC 8.4 and 8.6.
The following code was shrunk from code generated by the GHC backend of Agda. Agda in essence targets the untyped lambda calculus, thus, uses `unsafeCoerce` excessively. This was unproblematic until GHC 8.2 and seems to be fine again from GHC 8.8.
## Steps to reproduce
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module Main where
import Prelude (IO, ($), (.), (>>=), putStrLn)
import System.Exit (exitFailure)
import Unsafe.Coerce (unsafeCoerce)
sequ :: IO () -> IO a -> IO a
sequ c c' = c >>= \ _ -> c'
main :: IO ()
main =
unsafeCoerce sequ (putStrLn "Hello,") $
unsafeCoerce sequ (putStrLn "world!") $
exitFailure
```
With 8.4.x or 8.6.x run
```
ghc -O Main.hs
./Main
```
The output is
```
Hello,
```
and exitcode is 0.
## Expected behavior
Output [UPDATE: this output is produced when compiling with 8.8, 8.2, 8.0]
```
Hello,
world!
```
and exitcode 1.
## Environment
* GHC version used: 8.4.4 and 8.6.4
Optional:
* Operating System: Mac Mojavehttps://gitlab.haskell.org/ghc/ghc/-/issues/16713-fno-omit-yields doesn't work at -O02019-06-05T16:36:03Zroland-fno-omit-yields doesn't work at -O0```haskell
import Control.Concurrent
import Control.Monad
main = do
forkIO $ forever $ return ()
threadDelay 100000
putStrLn "done!"
````
In #8521 compiling with `-fno-omit-yields` was suggested, in order to make the tight loop y...```haskell
import Control.Concurrent
import Control.Monad
main = do
forkIO $ forever $ return ()
threadDelay 100000
putStrLn "done!"
````
In #8521 compiling with `-fno-omit-yields` was suggested, in order to make the tight loop yield. This appears to work at `-O1`:
```
$ ghc -O1 -threaded -fno-omit-yields Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o ) [Optimisation flags changed]
Linking Bug ...
$ ./Bug +RTS -N2
done!
```
...but not at `-O0`:
```
$ ghc -O0 -threaded -fno-omit-yields Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o ) [Optimisation flags changed]
Linking Bug ...
$ ./Bug +RTS -N2
^C^C
```
Also, I don't understand why `-fno-omit-yields` is at all required when running with `-N2`. If the `forever $ return ()` thread hogs one capability without yielding, wouldn't there be a second one left for the main thread to run on?
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5
```https://gitlab.haskell.org/ghc/ghc/-/issues/15732getArgsWithResponseFiles does not filter out RTS options2020-01-23T19:38:56ZChaitanya Koparkarckoparkar@gmail.comgetArgsWithResponseFiles does not filter out RTS optionsI discovered this while working on a fix for #15072.
`GHC.ResponseFile.getArgsWithResponseFiles` is a recent addition to `base-4.12`. The idea was to have a function which could read command-line arguments supplied via response files, b...I discovered this while working on a fix for #15072.
`GHC.ResponseFile.getArgsWithResponseFiles` is a recent addition to `base-4.12`. The idea was to have a function which could read command-line arguments supplied via response files, but otherwise
would behave exactly like `System.Environment.getArgs` (see #13896). However, these functions return different results when RTS options are supplied.
1. `getArgs` does not include RTS options in the list it returns.
1. `getArgsWithResponseFiles` includes them.
It's trivial to reproduce this. Consider these files:
```
-- Bug1.hs
module Main where
import System.Environment ( getArgs )
main :: IO ()
main = do
args <- getArgs
putStrLn $ "Args: " ++ show args
```
and
```
-- Bug2.hs
module Main where
import GHC.ResponseFile ( getArgsWithResponseFiles )
main :: IO ()
main = do
args <- getArgsWithResponseFiles
putStrLn $ "ArgsResp: " ++ show args
```
And run them with:
```sh
$ ghc-8.6.1 -rtsopts Bug1.hs && ghc-8.6.1 -rtsopts Bug2.hs
$ ./Bug1 1 +RTS -H32m -RTS 10 20
Args: ["1","10","20"]
-- 'opts_file' contains the same arguments passed to Bug1, and we
-- use a '@' to pass it as a response file
$ ./Bug2 @opts_file
ArgsResp: ["1","+RTS","-H32m","-RTS","10","20"]
```
We should fix `getArgsWithResponseFiles` to properly handle `+RTS ... -RTS` and `--RTS` flags. `getArgs` relies on the [runtime system](http://git.haskell.org/ghc.git/blob/HEAD:/rts/RtsFlags.c#l661) for this.https://gitlab.haskell.org/ghc/ghc/-/issues/15462fixST for lazy ST is a bit wrong2022-04-12T21:07:34ZDavid FeuerfixST for lazy ST is a bit wrong#15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`.
<details><summa...#15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"fixST for lazy ST is a bit wrong","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"#15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15312getChanContents exception behavior seems a bit odd2020-01-23T19:18:03ZDavid FeuergetChanContents exception behavior seems a bit oddI've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off:
```hs
-- Bug.hs
import Control.Concurrent (forkIO, yield)
import Control.Concurrent.Chan
import Data.List (elem)
import Control.Exception
import C...I've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off:
```hs
-- Bug.hs
import Control.Concurrent (forkIO, yield)
import Control.Concurrent.Chan
import Data.List (elem)
import Control.Exception
import Control.Concurrent.MVar
data Ex = Ex deriving Show
instance Exception Ex
main = do
ch <- newChan
sync1 <- newEmptyMVar
sync2 <- newEmptyMVar
forkIO $ do {writeList2Chan ch [1..3*10^6 :: Int]; putMVar sync1 ()}
yield
writeChan ch (-12)
cont <- getChanContents ch
tid <- forkIO $ do
evaluate (last cont)
putMVar sync2 ()
yield
throwTo tid Ex
print (elem (3*10^6) cont)
takeMVar sync1
tryTakeMVar sync2
```
When I run this single-threaded (`+RTS -N1`), it prints
```
Bug: Ex
Bug: Ex
```
One of the thunks in the lazy list gets overwritten by the (asynchronous) exception. This seems a bit surprising; is it the way it should be? Does `hGetContents` do this too?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getChanContents exception behavior seems a bit odd","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off:\r\n\r\n{{{#!hs\r\n-- Bug.hs\r\nimport Control.Concurrent (forkIO, yield)\r\nimport Control.Concurrent.Chan\r\nimport Data.List (elem)\r\nimport Control.Exception\r\nimport Control.Concurrent.MVar\r\n\r\ndata Ex = Ex deriving Show\r\ninstance Exception Ex\r\n\r\nmain = do\r\n ch <- newChan\r\n sync1 <- newEmptyMVar\r\n sync2 <- newEmptyMVar\r\n forkIO $ do {writeList2Chan ch [1..3*10^6 :: Int]; putMVar sync1 ()}\r\n yield\r\n writeChan ch (-12)\r\n cont <- getChanContents ch\r\n\r\n tid <- forkIO $ do\r\n evaluate (last cont)\r\n putMVar sync2 ()\r\n\r\n yield\r\n throwTo tid Ex\r\n\r\n\r\n print (elem (3*10^6) cont)\r\n takeMVar sync1\r\n tryTakeMVar sync2\r\n}}}\r\n\r\nWhen I run this single-threaded (`+RTS -N1`), it prints\r\n\r\n{{{\r\nBug: Ex\r\nBug: Ex\r\n}}}\r\n\r\nOne of the thunks in the lazy list gets overwritten by the (asynchronous) exception. This seems a bit surprising; is it the way it should be? Does `hGetContents` do this too?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15081Finite list becomes infinite after maping fractional function for high numbers2021-10-28T13:32:28ZOnsedFinite list becomes infinite after maping fractional function for high numbersTested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64.
- \*Code that produces wrong results\*\*
```
map (/2) [9007199254740990..9007199254740991]
```
- \*Expected behav...Tested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64.
- \*Code that produces wrong results\*\*
```
map (/2) [9007199254740990..9007199254740991]
```
- \*Expected behaviour\*\*
same as with low values:
```
map (/2) [5..6]
```
resulting in:
```
[2.5,3.0]
```
- \*Actual behaviour\*\*
resulting in an infinite list:
```
[4.503599627370495e15,4.5035996273704955e15,4.503599627370496e15..]
```
- \*Similar code that produces expected results\*\*
multiplication works:
```
map (*2) [9007199254740990..9007199254740991]
```
slightly smaller number work:
```
map (/2) [9007199254740989..9007199254740990]
```
using a comma to produce the same list works:
```
map (/2) [9007199254740990,9007199254740991]
```
- \*Similar code that also produces unexpected results\*\*
more elements in the list:
```
map (/2) [9007199254740990..9007199254740999]
map (/2) [9007199254740990..9007199354740999]
```
substituting the number and doing calculations:
```
map (/2) [9007199254740990..9007199254740990+1]
let a = 9007199254740990
map (/2) [a..a+1]
```
using scan and fold:
```
foldl1 (/) [9007199254740990..9007199254740991]
scanl1 (/) [9007199254740990..9007199254740991]
```
- \*Notes\*\*
This somehow only happens with high numbers when using fractional operations and using .. to construct the list.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Finite list becomes infinite after maping fractional function for high numbers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64.\r\n\r\n**Code that produces wrong results**\r\n{{{\r\nmap (/2) [9007199254740990..9007199254740991]\r\n}}}\r\n\r\n**Expected behaviour**\r\n\r\nsame as with low values:\r\n{{{\r\nmap (/2) [5..6]\r\n}}}\r\n\r\nresulting in:\r\n\r\n\r\n{{{\r\n[2.5,3.0]\r\n}}}\r\n\r\n**Actual behaviour**\r\n\r\nresulting in an infinite list:\r\n\r\n\r\n{{{\r\n[4.503599627370495e15,4.5035996273704955e15,4.503599627370496e15..]\r\n}}}\r\n\r\n**Similar code that produces expected results**\r\n\r\nmultiplication works:\r\n\r\n{{{\r\nmap (*2) [9007199254740990..9007199254740991]\r\n}}}\r\n\r\nslightly smaller number work:\r\n\r\n{{{\r\nmap (/2) [9007199254740989..9007199254740990]\r\n}}}\r\n\r\nusing a comma to produce the same list works:\r\n\r\n\r\n{{{\r\nmap (/2) [9007199254740990,9007199254740991]\r\n}}}\r\n\r\n**Similar code that also produces unexpected results**\r\n\r\nmore elements in the list:\r\n\r\n\r\n{{{\r\nmap (/2) [9007199254740990..9007199254740999]\r\nmap (/2) [9007199254740990..9007199354740999]\r\n}}}\r\n\r\n\r\nsubstituting the number and doing calculations:\r\n\r\n\r\n{{{\r\nmap (/2) [9007199254740990..9007199254740990+1]\r\nlet a = 9007199254740990\r\nmap (/2) [a..a+1]\r\n}}}\r\n\r\n\r\nusing scan and fold:\r\n\r\n\r\n{{{\r\nfoldl1 (/) [9007199254740990..9007199254740991]\r\nscanl1 (/) [9007199254740990..9007199254740991]\r\n}}}\r\n\r\n**Notes**\r\n\r\nThis somehow only happens with high numbers when using fractional operations and using .. to construct the list.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14946GHC Calls CPP for HS with -undef2019-07-07T18:14:56ZTamar ChristinaGHC Calls CPP for HS with -undefGHC Is calling the C preprocessor\[1\] when processing HS files with `-undef` which unsets the C compiler pre-defines.
Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support.
Is this...GHC Is calling the C preprocessor\[1\] when processing HS files with `-undef` which unsets the C compiler pre-defines.
Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support.
Is this really the intended behavior?
I get the fact that we're processing a Haskell source file, but why restrict the pre-processor to only GHC defines. You lose information like if unaligned accesses are supported or not etc.
\[1\] https://github.com/ghc/ghc/blob/60aa53d97da1bbfbb88e9f2791c3f686ba34e764/aclocal.m4\#L2241https://gitlab.haskell.org/ghc/ghc/-/issues/14901dsrun014 fails with most ways2023-06-30T18:38:57ZAlp Mestanogullaridsrun014 fails with most waysThe `dsrun014` test doesn't seem to pass for a whole bunch of ways, as a recent `./validate --slow` (against yesterday's master) revealed.
```py
# the test options
test('dsrun014', normal, compile_and_run, ['-fobject-code'])
```
```hs
...The `dsrun014` test doesn't seem to pass for a whole bunch of ways, as a recent `./validate --slow` (against yesterday's master) revealed.
```py
# the test options
test('dsrun014', normal, compile_and_run, ['-fobject-code'])
```
```hs
-- the haskell program we build & run
{-# LANGUAGE UnboxedTuples #-}
module Main where
import Debug.Trace
{-# NOINLINE f #-}
f :: a -> b -> (# a,b #)
f x y = x `seq` y `seq` (# x,y #)
g :: Int -> Int -> Int
g v w = case f v w of
(# a,b #) -> a+b
main = print (g (trace "one" 1) (trace "two" 2))
-- The args should be evaluated in the right order!
```
```
# the failing ways
/tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (hpc)
/tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (optasm)
/tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (threaded2)
/tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (dyn)
/tmp/ghctest-n4fi8zlk/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (optllvm)
```
With those 5 ways, the program's trace is `two` then `one` while with some other ways (like ghci or normal) we get (as expected by the testsuite) `one` first and `two` afterwards.
I'm not sure whether the expectation is too strong or whether there's something fishy going on with those 5 ways.
Simon, could you perhaps comment on this? Is this a "proper" bug?https://gitlab.haskell.org/ghc/ghc/-/issues/14769The RecompBecause [TH] check is not resume-build-safe2022-04-02T17:29:44ZNiklas Hambüchenmail@nh2.meThe RecompBecause [TH] check is not resume-build-safe`ghc --make` aims to make compilation behave correctly and produce up-to-date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed
At no point should interrupting a build and running it again produce "l...`ghc --make` aims to make compilation behave correctly and produce up-to-date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed
At no point should interrupting a build and running it again produce "less correct" outputs than running it to the end; specifically interrupting shouldn't result in necessary build steps to be "forgotten".
However, this seems to be the case with the `[TH]` check introduced in #481.
Minimal test case with 3 files: https://github.com/nh2/th-recomp-test
Good behaviour when running without interrupting:
```
% touch A.hs && ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs
[1 of 3] Compiling A ( A.hs, A.o )
[2 of 3] Compiling B ( B.hs, B.o ) [TH]
[3 of 3] Compiling Main ( Main.hs, Main.o ) [TH]
Linking Main ...
```
Bad behaviour when interrupting and running again:
```
% touch A.hs; timeout 0.1 ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs; ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs
[1 of 3] Compiling A ( A.hs, A.o )
[2 of 3] Compiling B ( B.hs, B.o ) [TH]
Linking Main ...
```
As you can see, when interrupting, the step `Compiling Main ( Main.hs, Main.o ) [TH]` went missing.
This suggests to me that either:
- the `[TH]`s are unnecessary in the first place (unlikely and I buy into the reason explained by #481 that changed values may be picked up by TH in higher-level modules)
- the resumed `ghc --make` invocation may potentially produce wrong / not-up-to-date outputs (most likely)
- re-running somehow retrieves the information that in fact recompiling `Main` is not necessary for a correct build (if this is the case, then I'd really like to know how that works and we should document it, likely also try to use that way to avoid recompiling `Main` in the uninterrupted run)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The RecompBecause [TH] check is not resume-build-safe","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2","simonmar"],"type":"Bug","description":"`ghc --make` aims to make compilation behave correctly and produce up-to-date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed\r\n\r\nAt no point should interrupting a build and running it again produce \"less correct\" outputs than running it to the end; specifically interrupting shouldn't result in necessary build steps to be \"forgotten\".\r\n\r\nHowever, this seems to be the case with the `[TH]` check introduced in #481.\r\n\r\nMinimal test case with 3 files: https://github.com/nh2/th-recomp-test\r\n\r\nGood behaviour when running without interrupting:\r\n\r\n{{{\r\n% touch A.hs && ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs \r\n[1 of 3] Compiling A ( A.hs, A.o )\r\n[2 of 3] Compiling B ( B.hs, B.o ) [TH]\r\n[3 of 3] Compiling Main ( Main.hs, Main.o ) [TH]\r\nLinking Main ...\r\n}}}\r\n\r\nBad behaviour when interrupting and running again:\r\n\r\n{{{\r\n% touch A.hs; timeout 0.1 ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs; ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs\r\n[1 of 3] Compiling A ( A.hs, A.o )\r\n[2 of 3] Compiling B ( B.hs, B.o ) [TH]\r\nLinking Main ...\r\n}}}\r\n\r\nAs you can see, when interrupting, the step `Compiling Main ( Main.hs, Main.o ) [TH]` went missing.\r\n\r\nThis suggests to me that either:\r\n\r\n* the `[TH]`s are unnecessary in the first place (unlikely and I buy into the reason explained by #481 that changed values may be picked up by TH in higher-level modules)\r\n* the resumed `ghc --make` invocation may potentially produce wrong / not-up-to-date outputs (most likely)\r\n* re-running somehow retrieves the information that in fact recompiling `Main` is not necessary for a correct build (if this is the case, then I'd really like to know how that works and we should document it, likely also try to use that way to avoid recompiling `Main` in the uninterrupted run)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13634num009 fails on POWER82022-01-16T09:37:43ZPeter Trommlerptrommler@acm.orgnum009 fails on POWER8This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running op...This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"num009 fails on POWER8","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd","hvr"],"type":"Bug","description":"This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:\r\n{{{\r\n+uh oh! tanf 1.5707964\r\n+-2.2877334e7\r\n+-2.2877332e7\r\n+(-11438667,1)\r\n+(-11438666,1)\r\n Done\r\n}}}\r\n\r\nThe test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13593Unexpected behavior from Data.List.groupBy2019-07-07T18:21:07ZdsfUnexpected behavior from Data.List.groupByI was hoping that
```hs
let notBoth1 a b = not (a == 1 && b == 1) in
groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1]
```
would give me
```
[[1],[1,2,3,1],[1,4,5,6,1]]
```
but instead I get
```
[[1],[1,2,3],[1],[1,4,5,6],[1]]
```
It seems t...I was hoping that
```hs
let notBoth1 a b = not (a == 1 && b == 1) in
groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1]
```
would give me
```
[[1],[1,2,3,1],[1,4,5,6,1]]
```
but instead I get
```
[[1],[1,2,3],[1],[1,4,5,6],[1]]
```
It seems that groupBy assumes transitivity in the argument function. I have a new implementation that does not make this assumption. Of course, the implications of changing this function's behavior are troubling.
```hs
groupBy' :: (a -> a -> Bool) -> [a] -> [[a]]
groupBy' p (x : xs) = go [x] xs
where
go (x : xs) (y : zs) | p x y = go (y : x : xs) zs
go g (y : zs) = reverse g : go [y] zs
go g [] = [reverse g]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpected behavior from Data.List.groupBy","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was hoping that\r\n{{{#!hs\r\nlet notBoth1 a b = not (a == 1 && b == 1) in\r\ngroupBy notBoth1 [1,1,2,3,1,1,4,5,6,1]\r\n}}}\r\nwould give me\r\n{{{\r\n[[1],[1,2,3,1],[1,4,5,6,1]]\r\n}}}\r\nbut instead I get\r\n{{{\r\n[[1],[1,2,3],[1],[1,4,5,6],[1]]\r\n}}}\r\nIt seems that groupBy assumes transitivity in the argument function. I have a new implementation that does not make this assumption. Of course, the implications of changing this function's behavior are troubling.\r\n{{{#!hs\r\ngroupBy' :: (a -> a -> Bool) -> [a] -> [[a]]\r\ngroupBy' p (x : xs) = go [x] xs\r\n where\r\n go (x : xs) (y : zs) | p x y = go (y : x : xs) zs\r\n go g (y : zs) = reverse g : go [y] zs\r\n go g [] = [reverse g]\r\n}}}","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->