GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-01-23T19:18:03Zhttps://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/7398RULES don't apply to a newtype constructor2020-01-23T19:38:31ZshachafRULES don't apply to a newtype constructorFor some reason, RULES that involve a newtype constructor never seem to fire. The following program demonstrates the problem:
```
module Main where
newtype Foo a = Foo { unFoo :: a }
deriving Show
foo :: a -> Foo a
foo = Foo
{-# RU...For some reason, RULES that involve a newtype constructor never seem to fire. The following program demonstrates the problem:
```
module Main where
newtype Foo a = Foo { unFoo :: a }
deriving Show
foo :: a -> Foo a
foo = Foo
{-# RULES "rule Foo" forall v. Foo v = error "Foo" #-}
{-# RULES "rule foo" forall v. foo v = error "foo" #-}
main :: IO ()
main = do
print (Foo ())
print (foo ())
```
"rule foo" fires, but "rule Foo" doesn't. The program prints
```
Foo {unFoo = ()}
D: foo
```
Note that this doesn't seem to affect selectors, only constructors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RULES don't apply to a newtype constructor","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For some reason, RULES that involve a newtype constructor never seem to fire. The following program demonstrates the problem:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nnewtype Foo a = Foo { unFoo :: a }\r\n deriving Show\r\n\r\nfoo :: a -> Foo a\r\nfoo = Foo\r\n\r\n{-# RULES \"rule Foo\" forall v. Foo v = error \"Foo\" #-}\r\n{-# RULES \"rule foo\" forall v. foo v = error \"foo\" #-}\r\n\r\nmain :: IO ()\r\nmain = do\r\n print (Foo ())\r\n print (foo ())\r\n}}}\r\n\r\n\"rule foo\" fires, but \"rule Foo\" doesn't. The program prints\r\n\r\n{{{\r\nFoo {unFoo = ()}\r\nD: foo\r\n}}}\r\n\r\nNote that this doesn't seem to affect selectors, only constructors.","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->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/7411Exceptions are optimized away in certain situations2020-05-27T16:04:30ZSimon Hengelsol@typeful.netExceptions are optimized away in certain situationsThe issue came up in [this thread on glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html).
## Steps to reproduce:
```hs
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
...The issue came up in [this thread on glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html).
## Steps to reproduce:
```hs
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
```
```
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs
```
### Expected result:
The program should fail with:
```
Foo: Prelude.undefined
```
### Actual result:
The program succeeds.
Compiling the program with `-fno-state-hack` helps.8.10.2Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://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/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/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/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/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/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/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/13584ghci parse error on operator info2021-01-20T10:16:18Zakegaljghci parse error on operator infoIf requested info about some operator, ie `(+)` `:info (+)` is working as expected:
```haskell
> :i (+)
class Num a where
(+) :: a -> a -> a
...
-- Defined in ‘GHC.Num’
infixl 6 +
```
When additional space character is there `:i...If requested info about some operator, ie `(+)` `:info (+)` is working as expected:
```haskell
> :i (+)
class Num a where
(+) :: a -> a -> a
...
-- Defined in ‘GHC.Num’
infixl 6 +
```
When additional space character is there `:info (+ )` it won't parse:
```haskell
> :i (+ )
<interactive>:1:3: error:
parse error (possibly incorrect indentation or mismatched brackets)
```
Note that the same thing is working with `:type` so its strange it doesn't use the same parser in both places:
```haskell
> :t (+ )
(+ ) :: Num a => a -> a -> a
```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/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/12656ghc floats out constant despite -fno-cse2021-04-24T22:31:54ZNiklas Hambüchenmail@nh2.meghc floats out constant despite -fno-cseConsider this program using `Data.Vector.unsafeThaw` and `-fno-cse`:
```
{-# OPTIONS_GHC -fno-cse #-}
import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM
main :: IO ()
main = do
foo 100000
foo 100000
le...Consider this program using `Data.Vector.unsafeThaw` and `-fno-cse`:
```
{-# OPTIONS_GHC -fno-cse #-}
import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM
main :: IO ()
main = do
foo 100000
foo 100000
let f = foo 100000 in f >> f
foo :: Int -> IO ()
foo n = do
indexVector <- V.unsafeThaw $ V.generate n id
x <- VM.read indexVector 5
VM.write indexVector 5 (x * x)
print x
-- In GHCI, we get:
--
-- > :set -fno-cse
--
-- > foo 100000
-- 5
-- > foo 100000
-- 5
--
-- > let f = foo 100000 in f >> f
-- 5
-- 25
```
I would expect that
```
> let f = foo 100000 in f >> f
5
5
```
Shouldn't `-fno-cse` fix this?
(Note: This also happens with `ghc` instead of `ghci`.)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/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/11261Implement DWARF debugging on powerpc642021-09-07T15:27:56ZPeter Trommlerptrommler@acm.orgImplement DWARF debugging on powerpc64debug:
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151219 for powerpc64-unknown-linux):
dwarfReturnRegNo: Unsupported platform!
CallStack (from ImplicitParams):
error, called at compiler/nativeGen/...debug:
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151219 for powerpc64-unknown-linux):
dwarfReturnRegNo: Unsupported platform!
CallStack (from ImplicitParams):
error, called at compiler/nativeGen/Dwarf/Constants.hs:224:19 in ghc:Dwarf.Constants
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Provide DWARF constants for registers.
Still TODO:
- [ ] add unwinding information to `StgCRun` to ensure that the unwinder can unwind from Haskell into C
- [ ] to support the RTS unwinder: add support to the initial register callback `set_initial_registers` in `rts/Libdw.c`
- [ ] Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`)
- [ ] Support in the native code generator (by implementing the `extractUnwindPoints` field of `NcgImpl`)
- [ ] Unwinding support in `libdw`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | debug, T10667 |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement DWARF debugging on powerpc64","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.11","keywords":[],"differentials":[],"test_case":"debug, T10667","architecture":"","cc":[""],"type":"Bug","description":"debug:\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20151219 for powerpc64-unknown-linux):\r\n dwarfReturnRegNo: Unsupported platform!\r\nCallStack (from ImplicitParams):\r\n error, called at compiler/nativeGen/Dwarf/Constants.hs:224:19 in ghc:Dwarf.Constants\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nProvide DWARF constants for registers.","type_of_failure":"OtherFailure","blocking":[]} -->⊥Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://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/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":[]} -->