GHC issues
https://gitlab.haskell.org/ghc/ghc/-/issues
2019-05-24T19:53:10Z
https://gitlab.haskell.org/ghc/ghc/-/issues/16617
On x86_64, `castFloatToWord32` can generate bad, signed `Word32`s
2019-05-24T19:53:10Z
KevinBuhr
On x86_64, `castFloatToWord32` can generate bad, signed `Word32`s
# Summary
On 64-bit architectures, when the primop `stgFloatToWord32#` is applied to a negative float (i.e., whose 32-bit representation has the sign bit set), it produces a sign-extended 64-bit word. As a result, `castFloatToWord32` a...
# Summary
On 64-bit architectures, when the primop `stgFloatToWord32#` is applied to a negative float (i.e., whose 32-bit representation has the sign bit set), it produces a sign-extended 64-bit word. As a result, `castFloatToWord32` applied to negative floats will generate weird negative `Word32`s.
# Steps to reproduce
Under GHCi:
```
> import GHC.Float
> castFloatToWord32 (-1)
-1082130432
> castFloatToWord32 (-1) < 0
False
> toInteger (castFloatToWord32 (-1)) < 0
True
>
```
# Expected behavior
One would expect `Word32`s to stay positive, even in the face of such adversity:
```
> castFloatToWord32 (-1)
3212836864
> toInteger (castFloatToWord32 (-1)) < 0
False
>
```
# Fix
The issue is that `stg_floatToWord32zh` in `libraries/base/cbits/CastFloatWord.cmm` uses:
```
w = TO_W_(I32[ptr])
```
where `TO_W_` is `%sx64` on 64-bit architectures. I'd suggest adding macros `TO_ZW_` to `Cmm.h` for zero-extending analogues of `TO_W_` and using that in `stg_floatToWord32zh`. (No one seems to be using `%zx32` or `%zx64` anywhere in the code base, but they might want to some day.)
I'd be happy to add a new test case and submit a patch.
# Environment
* GHC version used: 8.6.4 or latest HEAD
* Operating System: Linux
* System Architecture: x86_64
KevinBuhr
KevinBuhr
https://gitlab.haskell.org/ghc/ghc/-/issues/16222
PPC NCG: C calling convention violated for integers smaller than word size
2019-07-07T18:00:54Z
Peter Trommler
ptrommler@acm.org
PPC NCG: C calling convention violated for integers smaller than word size
The C calling convention for powerpc64 and powerpc64le require simple integer types to be zero or sign extended to 64 bit. The PPC NCG assumes that all values have been promoted to word size but now we introduced integer operations on sm...
The C calling convention for powerpc64 and powerpc64le require simple integer types to be zero or sign extended to 64 bit. The PPC NCG assumes that all values have been promoted to word size but now we introduced integer operations on smaller than machine word size and in general we cannot assume that values have been promoted anymore.
When a value is not promoted and passed to a foreign function on the stack that value will be in the wrong position within the stack slot on big endian systems and the function will deliver wrong results. On little endian systems we still get correct results as long as we stay in the smaller integer range.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, erikd, hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PPC NCG: C calling convention violated for integers smaller than word size","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"8.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["big","endian"],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","erikd","hvr","simonmar"],"type":"Bug","description":"The C calling convention for powerpc64 and powerpc64le require simple integer types to be zero or sign extended to 64 bit. The PPC NCG assumes that all values have been promoted to word size but now we introduced integer operations on smaller than machine word size and in general we cannot assume that values have been promoted anymore.\r\n\r\nWhen a value is not promoted and passed to a foreign function on the stack that value will be in the wrong position within the stack slot on big endian systems and the function will deliver wrong results. On little endian systems we still get correct results as long as we stay in the smaller integer range.","type_of_failure":"OtherFailure","blocking":[]} -->
8.10.1
Peter Trommler
ptrommler@acm.org
Peter Trommler
ptrommler@acm.org
https://gitlab.haskell.org/ghc/ghc/-/issues/16031
Show instance for Data.Fixed does not show parentheses for negatives
2019-07-07T18:01:57Z
Steven Keuchel
Show instance for Data.Fixed does not show parentheses for negatives
When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic:
```hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Prelude> show (Just (-1 :: Int))
"Just (-1)"
P...
When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic:
```hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Prelude> show (Just (-1 :: Int))
"Just (-1)"
Prelude> show (Just (-1 :: Float))
"Just (-1.0)"
```
However, the Show instance for Fixed does not
```hs
Prelude> :m Data.Fixed
Prelude Data.Fixed> show (Just (-1 :: Fixed E2))
"Just -1.00"
Prelude Data.Fixed>
```
I would expect it to, because of consistency and because the result "Just -1.00" is ill-typed when seen as an expression.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show instance for Data.Fixed does not show parentheses for negatives","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["Data.Fixed,","Show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic: \r\n\r\n{{{#!hs\r\nGHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help\r\nPrelude> show (Just (-1 :: Int))\r\n\"Just (-1)\"\r\nPrelude> show (Just (-1 :: Float))\r\n\"Just (-1.0)\"\r\n}}}\r\n\r\nHowever, the Show instance for Fixed does not\r\n\r\n{{{#!hs\r\nPrelude> :m Data.Fixed\r\nPrelude Data.Fixed> show (Just (-1 :: Fixed E2))\r\n\"Just -1.00\"\r\nPrelude Data.Fixed> \r\n}}}\r\n\r\nI would expect it to, because of consistency and because the result \"Just -1.00\" is ill-typed when seen as an expression.","type_of_failure":"OtherFailure","blocking":[]} -->
8.8.1
Sven Tennie
Sven Tennie
https://gitlab.haskell.org/ghc/ghc/-/issues/15856
GhostScript not available for hp2ps tests
2019-07-07T18:02:42Z
jrp2014
GhostScript not available for hp2ps tests
When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer...
When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).
The message "GhostScript not available for hp2ps tests" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.
There are probably 2 ways forward:
- a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable
- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GhostScript not available for hp2ps tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["ghostscript","gs","hp2ps","testsuite"],"differentials":[],"test_case":"","architecture":"","cc":["Simonmar"],"type":"Bug","description":"When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.\r\n\r\nI don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).\r\n\r\nThe message \"GhostScript not available for hp2ps tests\" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.\r\n\r\nThere are probably 2 ways forward:\r\n\r\n - a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable\r\n\r\n- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that","type_of_failure":"OtherFailure","blocking":[]} -->
8.8.1
Krzysztof Gogolewski
Krzysztof Gogolewski
https://gitlab.haskell.org/ghc/ghc/-/issues/15715
problematic openFile with named pipes
2019-07-07T18:03:19Z
adp
problematic openFile with named pipes
- while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the proc...
- while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the process hearing on the other side didn't hear anything).
- `writeFile` and `appendFile` works though.
- using stack `resolver: lts-12.4`, on ubuntu 16.04 LTS
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"problematic openFile with named pipes","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"- while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the process hearing on the other side didn't hear anything).\r\n\r\n- `writeFile` and `appendFile` works though.\r\n\r\n- using stack `resolver: lts-12.4`, on ubuntu 16.04 LTS\r\n","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->
8.6.3
https://gitlab.haskell.org/ghc/ghc/-/issues/15686
Different results depending on if the code was compiled with or without optim...
2019-07-07T18:03:27Z
Darwin226
Different results depending on if the code was compiled with or without optimizations
The test case consists of three files:
Main.hs
```hs
{-# LANGUAGE OverloadedLists, BangPatterns #-}
{-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-}
module Main where
import Mesh
import Vec
import Control.Exception
main...
The test case consists of three files:
Main.hs
```hs
{-# LANGUAGE OverloadedLists, BangPatterns #-}
{-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-}
module Main where
import Mesh
import Vec
import Control.Exception
main :: IO ()
main = do
!_ <- evaluate $ toBondForce (Particle {_position = Vec {_vecX = 0.0, _vecY = -20.0}, _mass = 10.0, _velocity = Vec {_vecX = 0.0, _vecY = 3.0}}) (Particle {_position = Vec {_vecX = 20.0, _vecY = -20.0}, _mass = 10.0, _velocity = Vec {_vecX = 0.0, _vecY = 0.0}}) (FixedDistanceBond {_distance = 20.0, _strength = 0.5})
return ()
```
Vec.hs
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, FunctionalDependencies #-}
module Vec where
data Vec = Vec { _vecX :: {-# UNPACK #-}!Double, _vecY :: {-# UNPACK #-}!Double }
deriving (Eq, Ord, Read, Show)
liftVec :: (Double -> Double -> Double) -> Vec -> Vec -> Vec
liftVec f (Vec x y) (Vec z w) = Vec (f x z) (f y w)
{-# INLINE liftVec #-}
instance Num Vec where
fromInteger i = Vec (fromInteger i) (fromInteger i)
(+) a b = liftVec (+) a b
{-# INLINE (+) #-}
(*) a b = liftVec (*) a b
{-# INLINE (*) #-}
(-) a b = liftVec (-) a b
{-# INLINE (-) #-}
signum (Vec x y) = Vec (signum x) (signum y)
abs (Vec x y) = Vec (abs x) (abs y)
instance Fractional Vec where
fromRational r = Vec (fromRational r) (fromRational r)
(/) = liftVec (/)
{-# INLINE (/) #-}
fromDouble :: Double -> Vec
fromDouble x = Vec x x
{-# INLINE fromDouble #-}
class Vector2D v where
norm :: v -> Double
normalize :: v -> v
distance :: v -> v -> Double
dot :: v -> v -> Double
project :: v -> v -> v
instance Vector2D Vec where
norm (Vec x y) = sqrt (x ** 2 + y ** 2)
{-# INLINE norm #-}
normalize v@(Vec x y) = Vec (x / n) (y / n)
where
n = norm v
{-# INLINE normalize #-}
distance v1 v2 = norm (v2 - v1)
{-# INLINE distance #-}
dot (Vec x y) (Vec z w) = x * z + y * w
{-# INLINE dot #-}
project tgt v = normTgt * realToFrac (dot normTgt v)
where normTgt = normalize tgt
{-# INLINE project #-}
```
Mesh.hs
```hs
{-# LANGUAGE Strict, RecordWildCards, TemplateHaskell, BangPatterns #-}
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, FunctionalDependencies #-}
{-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-}
module Mesh where
import Vec
import Debug.Trace
data Particle = Particle
{ _position :: {-# UNPACK #-}!Vec
, _mass :: {-# UNPACK #-}!Double
, _velocity :: {-# UNPACK #-}!Vec }
deriving (Eq, Ord, Read, Show)
data Bond = FixedDistanceBond
{ _distance :: {-# UNPACK #-}!Double
, _strength :: {-# UNPACK #-}!Double }
deriving (Eq, Ord, Read, Show)
toBondForce :: Particle -> Particle -> Bond -> Vec
toBondForce Particle{..} !p2 FixedDistanceBond{..} =
traceShow (show (Mesh._position p2, dir)) $ dir * fromDouble (actualDist - _distance) * fromDouble _strength - project dir velDiff * 0.1
where
posDiff = Mesh._position p2 - _position
dir = normalize posDiff
actualDist = norm posDiff
velDiff = _velocity - Mesh._velocity p2
```
Compiling Main.hs with optimizations (-O2) and running the program produces the output "(Vec {_vecX = 20.0, _vecY = 0.0},Vec {_vecX = 1.0, _vecY = 0.0})" while compiling without optimizations produces "(Vec {_vecX = 20.0, _vecY = -20.0},Vec {_vecX = 1.0, _vecY = 0.0})" which is correct.
Further observations:
Changing `traceShow (show (Mesh._position p2, dir))` to `traceShow (show (Mesh._position p2))` makes the code perform correctly even with optimizations.
The core output looks correct to me even with optimizations.
I can't test with other GHC versions on Windows, but I know I can't reproduce this with GHC 8.4 on Linux and I think it also doesn't reproduce with 8.2 on Linux.
<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":"Different results depending on if the code was compiled with or without optimizations","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":"The test case consists of three files:\r\n\r\nMain.hs\r\n{{{#!hs\r\n{-# LANGUAGE OverloadedLists, BangPatterns #-}\r\n{-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-}\r\nmodule Main where\r\n\r\nimport Mesh\r\nimport Vec\r\nimport Control.Exception\r\n\r\nmain :: IO ()\r\nmain = do\r\n !_ <- evaluate $ toBondForce (Particle {_position = Vec {_vecX = 0.0, _vecY = -20.0}, _mass = 10.0, _velocity = Vec {_vecX = 0.0, _vecY = 3.0}}) (Particle {_position = Vec {_vecX = 20.0, _vecY = -20.0}, _mass = 10.0, _velocity = Vec {_vecX = 0.0, _vecY = 0.0}}) (FixedDistanceBond {_distance = 20.0, _strength = 0.5})\r\n return ()\r\n}}}\r\n\r\nVec.hs\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, FunctionalDependencies #-}\r\nmodule Vec where\r\n\r\ndata Vec = Vec { _vecX :: {-# UNPACK #-}!Double, _vecY :: {-# UNPACK #-}!Double }\r\n deriving (Eq, Ord, Read, Show)\r\n\r\nliftVec :: (Double -> Double -> Double) -> Vec -> Vec -> Vec\r\nliftVec f (Vec x y) (Vec z w) = Vec (f x z) (f y w)\r\n{-# INLINE liftVec #-}\r\n\r\ninstance Num Vec where\r\n fromInteger i = Vec (fromInteger i) (fromInteger i)\r\n (+) a b = liftVec (+) a b\r\n {-# INLINE (+) #-}\r\n (*) a b = liftVec (*) a b\r\n {-# INLINE (*) #-}\r\n (-) a b = liftVec (-) a b\r\n {-# INLINE (-) #-}\r\n signum (Vec x y) = Vec (signum x) (signum y)\r\n abs (Vec x y) = Vec (abs x) (abs y)\r\ninstance Fractional Vec where\r\n fromRational r = Vec (fromRational r) (fromRational r)\r\n (/) = liftVec (/)\r\n {-# INLINE (/) #-}\r\n\r\nfromDouble :: Double -> Vec\r\nfromDouble x = Vec x x\r\n{-# INLINE fromDouble #-}\r\n\r\nclass Vector2D v where\r\n norm :: v -> Double\r\n normalize :: v -> v\r\n distance :: v -> v -> Double\r\n dot :: v -> v -> Double\r\n project :: v -> v -> v\r\n\r\ninstance Vector2D Vec where\r\n norm (Vec x y) = sqrt (x ** 2 + y ** 2)\r\n {-# INLINE norm #-}\r\n\r\n normalize v@(Vec x y) = Vec (x / n) (y / n)\r\n where\r\n n = norm v\r\n {-# INLINE normalize #-}\r\n\r\n distance v1 v2 = norm (v2 - v1)\r\n {-# INLINE distance #-}\r\n\r\n dot (Vec x y) (Vec z w) = x * z + y * w\r\n {-# INLINE dot #-}\r\n\r\n project tgt v = normTgt * realToFrac (dot normTgt v)\r\n where normTgt = normalize tgt\r\n {-# INLINE project #-}\r\n\r\n}}}\r\n\r\nMesh.hs\r\n{{{#!hs\r\n{-# LANGUAGE Strict, RecordWildCards, TemplateHaskell, BangPatterns #-}\r\n{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, FunctionalDependencies #-}\r\n{-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-}\r\nmodule Mesh where\r\n\r\nimport Vec\r\nimport Debug.Trace\r\n\r\ndata Particle = Particle\r\n { _position :: {-# UNPACK #-}!Vec\r\n , _mass :: {-# UNPACK #-}!Double\r\n , _velocity :: {-# UNPACK #-}!Vec }\r\n deriving (Eq, Ord, Read, Show)\r\n\r\ndata Bond = FixedDistanceBond\r\n { _distance :: {-# UNPACK #-}!Double\r\n , _strength :: {-# UNPACK #-}!Double }\r\n deriving (Eq, Ord, Read, Show)\r\n\r\ntoBondForce :: Particle -> Particle -> Bond -> Vec\r\ntoBondForce Particle{..} !p2 FixedDistanceBond{..} =\r\n traceShow (show (Mesh._position p2, dir)) $ dir * fromDouble (actualDist - _distance) * fromDouble _strength - project dir velDiff * 0.1\r\n where\r\n posDiff = Mesh._position p2 - _position\r\n dir = normalize posDiff\r\n actualDist = norm posDiff\r\n velDiff = _velocity - Mesh._velocity p2\r\n\r\n}}}\r\n\r\nCompiling Main.hs with optimizations (-O2) and running the program produces the output \"(Vec {_vecX = 20.0, _vecY = 0.0},Vec {_vecX = 1.0, _vecY = 0.0})\" while compiling without optimizations produces \"(Vec {_vecX = 20.0, _vecY = -20.0},Vec {_vecX = 1.0, _vecY = 0.0})\" which is correct.\r\n\r\nFurther observations:\r\nChanging `traceShow (show (Mesh._position p2, dir))` to `traceShow (show (Mesh._position p2))` makes the code perform correctly even with optimizations.\r\nThe core output looks correct to me even with optimizations.\r\n\r\nI can't test with other GHC versions on Windows, but I know I can't reproduce this with GHC 8.4 on Linux and I think it also doesn't reproduce with 8.2 on Linux.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.1
https://gitlab.haskell.org/ghc/ghc/-/issues/15460
Literals overflow
2019-07-07T18:04:41Z
Sylvain Henry
Literals overflow
Consider the following example:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
print x
```
It gets desugared into:
```hs
m...
Consider the following example:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
print x
```
It gets desugared into:
```hs
main
= print
@ Int
GHC.Show.$fShowInt
(GHC.Types.I#
7237005577332262213973186563042994240829374041602535252466099000494570602495#)
```
Problem: the literal value isn't rounded and there is no overflow warning.
It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
if (x > maxBound)
then print "Oups"
else print "Ok"
> ghc TestLitOverflow.hs -Wall -O0
> ./TestLitOverflow
"Ok"
> ghc TestLitOverflow.hs -Wall -O2
> ./TestLitOverflow
"Oups"
```
8.8.1
Alec Theriault
Alec Theriault
https://gitlab.haskell.org/ghc/ghc/-/issues/15349
fixST is a bit wrong
2019-07-07T18:13:03Z
David Feuer
fixST is a bit wrong
Lazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRe...
Lazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRef ref
if x
then do
writeSTRef ref False
return $! (res + 5)
else return 10
main = print $ runST foo
```
When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.
Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| 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":"fixST is a bit wrong","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Lazy blackholing lets some `ST` calculations complete that shouldn't.\r\n\r\n{{{#!hs\r\nimport Control.Monad.ST.Strict\r\nimport Control.Monad.Fix\r\nimport Data.STRef\r\n\r\nfoo :: ST s Int\r\nfoo = do\r\n ref <- newSTRef True\r\n mfix $ \\res -> do\r\n x <- readSTRef ref\r\n if x\r\n then do\r\n writeSTRef ref False\r\n return $! (res + 5)\r\n else return 10\r\n\r\nmain = print $ runST foo\r\n}}}\r\n\r\nWhen this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.\r\n\r\nShould we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?","type_of_failure":"OtherFailure","blocking":[]} -->
8.6.1
David Feuer
David Feuer
https://gitlab.haskell.org/ghc/ghc/-/issues/15301
Regression in Natural desugaring
2019-07-07T18:13:22Z
Sylvain Henry
Regression in Natural desugaring
My recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadat...
My recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression in Natural desugaring","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My recent merged patch \"Built-in Natural literals in Core\" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.\r\n\r\nPatch coming.","type_of_failure":"OtherFailure","blocking":[]} -->
8.6.1
https://gitlab.haskell.org/ghc/ghc/-/issues/15271
1e1000000000 :: Double yields 0.0 instead of Infinity
2019-07-07T18:13:30Z
claude
1e1000000000 :: Double yields 0.0 instead of Infinity
(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd...
(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64):
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e100000000 :: Double
Infinity
(5.70 secs, 68,552 bytes)
Prelude> 1e1000000000 :: Double
0.0
(69.35 secs, 60,088 bytes)
```
Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases.
More precisely,
```
Prelude> 1e646457008 :: Double
Infinity
(40.80 secs, 64,272 bytes)
Prelude> 1e646457009 :: Double
0.0
(40.46 secs, 60,088 bytes)
```
Note:
```hs
(floor $ 2^31 / logBase 2 10 + 16) == 646457009
```
This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?).
Standalone test program:
```hs
main = do
print 1e646457008
print 1e646457009
```
Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help).
```
$ ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e646457008 :: Double
Infinity
(415.26 secs, 17,908 bytes)
Prelude> 1e646457009 :: Double
Infinity
(417.66 secs, 17,820 bytes)
Prelude> 1e746457298 :: Double
Infinity
(490.00 secs, 17,820 bytes)
Prelude> 1e1000000000 :: Double
GNU MP: Cannot allocate memory (size=419438600)
Aborted
$
```
`ghci-8.0.2` on Debian Buster amd64 exhibits the problem also.
8.6.3
Zhou Fangyi
Zhou Fangyi
https://gitlab.haskell.org/ghc/ghc/-/issues/15225
`-fno-state-hack` produces incorrect results in nofib
2019-07-07T18:13:43Z
Tobias Dammers
tdammers@gmail.com
`-fno-state-hack` produces incorrect results in nofib
While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.
A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:
- Compile GHC from scratch with:
> `
>...
While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.
A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:
- Compile GHC from scratch with:
> `
> GhcStage2HcOpts = -O -fno-state-hack
> GhcLibHcOpts = -O -fno-state-hack
> `
- Run nofib with `EXTRA_HC_OPTS=-fno-state-hack`
Doing this, the nofib test output is:
```
------------------------------------------------------------------------
== make all --no-print-directory;
in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta
------------------------------------------------------------------------
HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring
RUNTEST_OPTS = -ghc-timing
==nofib== fasta: time to compile Main follows...
/home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o
Main.hs:30:1: warning: [-Wtabs]
Tab character found here, and in 13 further locations.
Please use spaces instead.
|
30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1))
| ^^^^^^^^
<<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>>
==nofib== fasta: size of Main.o follows...
text data bss dec hex filename
7245 2624 0 9869 268d Main.o
==nofib== fasta: time to link fasta follows...
<<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>>
==nofib== fasta: size of fasta follows...
text data bss dec hex filename
708996 127712 16232 852940 d03cc fasta
==nofib== fasta: time to run fasta follows...
../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000;
0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k
0inputs+49656outputs (0major+608minor)pagefaults 0swaps
././fasta 2500000 < /dev/null
expected stdout not matched by reality
--- fasta.stdout 2018-06-02 03:00:43.887025433 +0200
+++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200
@@ -83337,333335 +83337,333335 @@
cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg
-tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa
-NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt
-cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga
-gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa
-HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca
#### ~3.1 million similar lines follow ####
-taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
#### ~208k identical lines follow
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
taatagccgagagaaattac
../../mk/target.mk:101: recipe for target 'runtests' failed
make[2]: *** [runtests] Error 1
Failed making all in fasta: 1
../mk/ghc-recurse.mk:65: recipe for target 'all' failed
make[1]: *** [all] Error 1
Failed making all in shootout: 1
mk/ghc-recurse.mk:65: recipe for target 'all' failed
make: *** [all] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"`-fno-state-hack` produces incorrect results in nofib","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.\r\n\r\nA vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:\r\n\r\n- Compile GHC from scratch with:\r\n {{{\r\n GhcStage2HcOpts = -O -fno-state-hack\r\n GhcLibHcOpts = -O -fno-state-hack\r\n }}}\r\n- Run nofib with `EXTRA_HC_OPTS=-fno-state-hack`\r\n\r\nDoing this, the nofib test output is:\r\n{{{\r\n------------------------------------------------------------------------\r\n== make all --no-print-directory;\r\n in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta\r\n------------------------------------------------------------------------\r\nHC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2\r\nHC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring\r\nRUNTEST_OPTS = -ghc-timing\r\n==nofib== fasta: time to compile Main follows...\r\n/home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o\r\n\r\nMain.hs:30:1: warning: [-Wtabs]\r\n Tab character found here, and in 13 further locations.\r\n Please use spaces instead.\r\n |\r\n30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1))\r\n | ^^^^^^^^\r\n<<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>>\r\n==nofib== fasta: size of Main.o follows...\r\n text\t data\t bss\t dec\t hex\tfilename\r\n 7245\t 2624\t 0\t 9869\t 268d\tMain.o\r\n==nofib== fasta: time to link fasta follows...\r\n<<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>>\r\n==nofib== fasta: size of fasta follows...\r\n text\t data\t bss\t dec\t hex\tfilename\r\n 708996\t 127712\t 16232\t 852940\t d03cc\tfasta\r\n==nofib== fasta: time to run fasta follows...\r\n../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000;\r\n0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k\r\n0inputs+49656outputs (0major+608minor)pagefaults 0swaps\r\n././fasta 2500000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- fasta.stdout\t2018-06-02 03:00:43.887025433 +0200\r\n+++ /tmp/runtest4673.1\t2018-06-02 03:09:19.651755697 +0200\r\n@@ -83337,333335 +83337,333335 @@\r\n cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg\r\n-tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa\r\n-NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt\r\n-cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga\r\n-gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa\r\n-HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca\r\n#### ~3.1 million similar lines follow ####\r\n-taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n#### ~208k identical lines follow\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n taatagccgagagaaattac\r\n../../mk/target.mk:101: recipe for target 'runtests' failed\r\nmake[2]: *** [runtests] Error 1\r\nFailed making all in fasta: 1\r\n../mk/ghc-recurse.mk:65: recipe for target 'all' failed\r\nmake[1]: *** [all] Error 1\r\nFailed making all in shootout: 1\r\nmk/ghc-recurse.mk:65: recipe for target 'all' failed\r\nmake: *** [all] Error 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->
8.6.1
Tobias Dammers
tdammers@gmail.com
Tobias Dammers
tdammers@gmail.com
https://gitlab.haskell.org/ghc/ghc/-/issues/15198
`Language.Haskell.TH.Syntax.reify` returns * rather than Constraint
2019-07-07T18:13:50Z
benzrf
`Language.Haskell.TH.Syntax.reify` returns * rather than Constraint
This module is sufficient to demonstrate the mistake:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Data.Kind
import Data.Pro...
This module is sufficient to demonstrate the mistake:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Data.Kind
import Data.Proxy
import Language.Haskell.TH
foo :: forall (k :: Constraint). Proxy k
foo = Proxy
return [] -- delimit declaration groups
main :: IO ()
main = putStrLn $(do
VarI _ ty _ <- reify 'foo
let p = pprint ty
[| p |])
```
Running this in GHC 8.0.2 correctly prints out `forall (k_0 :: Constraint) . Data.Proxy.Proxy k_0`, but GHC 8.2.2 and 8.4.2 both print `forall (k_0 :: *) . Data.Proxy.Proxy k_0`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`Language.Haskell.TH.Syntax.reify` returns * rather than Constraint","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.4.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":["constraint","constraintkinds","reify"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module is sufficient to demonstrate the mistake:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\nimport Data.Proxy\r\nimport Language.Haskell.TH\r\n\r\nfoo :: forall (k :: Constraint). Proxy k\r\nfoo = Proxy\r\n\r\nreturn [] -- delimit declaration groups\r\n\r\nmain :: IO ()\r\nmain = putStrLn $(do\r\n VarI _ ty _ <- reify 'foo\r\n let p = pprint ty\r\n [| p |])\r\n}}}\r\n\r\nRunning this in GHC 8.0.2 correctly prints out `forall (k_0 :: Constraint) . Data.Proxy.Proxy k_0`, but GHC 8.2.2 and 8.4.2 both print `forall (k_0 :: *) . Data.Proxy.Proxy k_0`.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.4
https://gitlab.haskell.org/ghc/ghc/-/issues/15158
T8089 failing with ghci, threaded1, threaded2, profthreaded
2019-07-07T18:14:00Z
Alp Mestanogullari
T8089 failing with ghci, threaded1, threaded2, profthreaded
```
=====> T8089(ghci) 17 of 17 [2, 16, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" T8089.hs -dcore-lint -dcmm-lint -no-...
```
=====> T8089(ghci) 17 of 17 [2, 16, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < T8089.genscript
Wrong exit code for T8089(ghci) (expected 99 , actual 0 )
*** unexpected failure for T8089(ghci)
=====> T8089(threaded1) 17 of 17 [2, 17, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089
Wrong exit code for T8089(threaded1)(expected 99 , actual 0 )
*** unexpected failure for T8089(threaded1)
=====> T8089(threaded2) 17 of 17 [2, 18, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -N2 -ls -RTS
Wrong exit code for T8089(threaded2)(expected 99 , actual 0 )
*** unexpected failure for T8089(threaded2)
=====> T8089(profthreaded) 17 of 17 [2, 19, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -p -RTS
Wrong exit code for T8089(profthreaded)(expected 99 , actual 0 )
*** unexpected failure for T8089(profthreaded)
```
I'm going to write a patch to expect the test to be broken in these ways, but it seems really wrong that the exit code we get is not the same accross all ways.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #8089 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T8089 failing with ghci, threaded1, threaded2, profthreaded","status":"New","operating_system":"","component":"libraries/base","related":[8089],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> T8089(ghci) 17 of 17 [2, 16, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < T8089.genscript\r\nWrong exit code for T8089(ghci) (expected 99 , actual 0 )\r\n*** unexpected failure for T8089(ghci)\r\n=====> T8089(threaded1) 17 of 17 [2, 17, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug \r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && ./T8089 \r\nWrong exit code for T8089(threaded1)(expected 99 , actual 0 )\r\n*** unexpected failure for T8089(threaded1)\r\n=====> T8089(threaded2) 17 of 17 [2, 18, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog \r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && ./T8089 +RTS -N2 -ls -RTS \r\nWrong exit code for T8089(threaded2)(expected 99 , actual 0 )\r\n*** unexpected failure for T8089(threaded2) \r\n=====> T8089(profthreaded) 17 of 17 [2, 19, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded \r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && ./T8089 +RTS -p -RTS \r\nWrong exit code for T8089(profthreaded)(expected 99 , actual 0 )\r\n*** unexpected failure for T8089(profthreaded)\r\n}}}\r\n\r\nI'm going to write a patch to expect the test to be broken in these ways, but it seems really wrong that the exit code we get is not the same accross all ways.","type_of_failure":"OtherFailure","blocking":[]} -->
8.6.1
https://gitlab.haskell.org/ghc/ghc/-/issues/15068
Small number of test case failures on Ubuntu Bionic (GCC 7.3)
2019-07-07T18:14:24Z
jrp2014
Small number of test case failures on Ubuntu Bionic (GCC 7.3)
A few tests (T13658 T14779a T14779b T14868 debug parsing001) fail running validate using HEAD and 8.4.1. They produce output similar to that shown below.
I am not quite sure how to test with clang. Just setting and exporting the environ...
A few tests (T13658 T14779a T14779b T14868 debug parsing001) fail running validate using HEAD and 8.4.1. They produce output similar to that shown below.
I am not quite sure how to test with clang. Just setting and exporting the environment variable CC to /usr/bin/clang (6) and running validate seemed to produce similar failures.
I was unable to try with LLVM because that now seems to be on version 6, which doesn't build.
```
=====> cgrun004(normal) 290 of 6344 [0, 0, 0]
cd "/tmp/ghctest-lx7q03iz/test spaces/./codeGen/should_run/cgrun004.run" && "/home/jrp/Projects/ghc/bindisttest/install dir/bin
/ghc" -o cgrun004 cgrun004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-gr
oups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output
Wrong exit code for debug()(expected 0 , actual 2 )
Stdout ( debug ):
== Dbg ==
src<debug.hs:(3,1)-(5,29)>
src<debug.hs:3:9>
src<debug.hs:4:9>
src<debug.hs:5:13-17>
src<debug.hs:5:14>
src<debug.hs:5:21-29>
src<debug.hs:5:25-29>
src<debug.hs:5:26>
src<debug.hs:5:9-17>
src<debug.hs:5:9-29>
src<debug.hs:6:1-21>
Makefile:12: recipe for target 'debug' failed
Stderr ( debug ):
/tmp/ghc152350_0/ghc_2.s: Assembler messages:
/tmp/ghc152350_0/ghc_2.s:1364:0: error:
Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'
/tmp/ghc152350_0/ghc_2.s:1393:0: error:
Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'
/tmp/ghc152350_0/ghc_2.s:1422:0: error:
Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'
/tmp/ghc152350_0/ghc_2.s:1451:0: error:
Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'
`gcc' failed in phase `Assembler'. (Exit code: 1)
make[1]: ./debug: Command not found
make[1]: *** [debug] Error 127
*** unexpected failure for debug(normal)
```
The tool versions are:
```
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30
```
```
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Small number of test case failures on Ubuntu Bionic (GCC 7.3)","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A few tests (T13658 T14779a T14779b T14868 debug parsing001) fail running validate using HEAD and 8.4.1. They produce output similar to that shown below.\r\n\r\nI am not quite sure how to test with clang. Just setting and exporting the environment variable CC to /usr/bin/clang (6) and running validate seemed to produce similar failures.\r\n\r\nI was unable to try with LLVM because that now seems to be on version 6, which doesn't build.\r\n\r\n{{{\r\n=====> cgrun004(normal) 290 of 6344 [0, 0, 0]\r\ncd \"/tmp/ghctest-lx7q03iz/test spaces/./codeGen/should_run/cgrun004.run\" && \"/home/jrp/Projects/ghc/bindisttest/install dir/bin\r\n/ghc\" -o cgrun004 cgrun004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-gr\r\noups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output \r\nWrong exit code for debug()(expected 0 , actual 2 )\r\nStdout ( debug ):\r\n== Dbg ==\r\nsrc<debug.hs:(3,1)-(5,29)>\r\nsrc<debug.hs:3:9>\r\nsrc<debug.hs:4:9>\r\nsrc<debug.hs:5:13-17>\r\nsrc<debug.hs:5:14>\r\nsrc<debug.hs:5:21-29>\r\nsrc<debug.hs:5:25-29>\r\nsrc<debug.hs:5:26>\r\nsrc<debug.hs:5:9-17>\r\nsrc<debug.hs:5:9-29>\r\nsrc<debug.hs:6:1-21>\r\nMakefile:12: recipe for target 'debug' failed\r\nStderr ( debug ):\r\n/tmp/ghc152350_0/ghc_2.s: Assembler messages:\r\n\r\n/tmp/ghc152350_0/ghc_2.s:1364:0: error:\r\n Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'\r\n\r\n/tmp/ghc152350_0/ghc_2.s:1393:0: error:\r\n Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'\r\n\r\n/tmp/ghc152350_0/ghc_2.s:1422:0: error:\r\n Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'\r\n\r\n/tmp/ghc152350_0/ghc_2.s:1451:0: error:\r\n Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'\r\n`gcc' failed in phase `Assembler'. (Exit code: 1)\r\nmake[1]: ./debug: Command not found\r\nmake[1]: *** [debug] Error 127\r\n*** unexpected failure for debug(normal)\r\n}}}\r\n\r\nThe tool versions are:\r\n\r\n{{{\r\nGNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30\r\n}}}\r\n\r\n\r\n{{{\r\nCOLLECT_GCC=gcc\r\nCOLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper\r\nOFFLOAD_TARGET_NAMES=nvptx-none\r\nOFFLOAD_TARGET_DEFAULT=1\r\nTarget: x86_64-linux-gnu\r\nConfigured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu\r\nThread model: posix\r\ngcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.3
https://gitlab.haskell.org/ghc/ghc/-/issues/14970
GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled
2019-07-07T18:14:51Z
rotaerk
GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled
When you run 'error', it shows the usual stack trace. When you enable profiling with the -prof flag to ghc, and you run 'error', it shows the usual stack trace plus an additional prof-specific stack trace.
When you run 'errorWithoutStac...
When you run 'error', it shows the usual stack trace. When you enable profiling with the -prof flag to ghc, and you run 'error', it shows the usual stack trace plus an additional prof-specific stack trace.
When you run 'errorWithoutStackTrace' with profiling enabled, it strips the usual stack trace of 'error', but still displays the prof-specific stack trace.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When you run 'error', it shows the usual stack trace. When you enable profiling with the -prof flag to ghc, and you run 'error', it shows the usual stack trace plus an additional prof-specific stack trace.\r\n\r\nWhen you run 'errorWithoutStackTrace' with profiling enabled, it strips the usual stack trace of 'error', but still displays the prof-specific stack trace.","type_of_failure":"OtherFailure","blocking":[]} -->
8.6.1
Simon Marlow
Simon Marlow
https://gitlab.haskell.org/ghc/ghc/-/issues/14967
Optimizer Casting Caf with nominal type
2019-07-07T18:14:51Z
etn
Optimizer Casting Caf with nominal type
When you make a function with a constant result, the optimizer will turn it into a cast of a CAF, even if doing so coerces a nominal parameter into a different one.
Minimal Example program:
```hs
{-# LANGUAGE RoleAnnotations #-}
import...
When you make a function with a constant result, the optimizer will turn it into a cast of a CAF, even if doing so coerces a nominal parameter into a different one.
Minimal Example program:
```hs
{-# LANGUAGE RoleAnnotations #-}
import Debug.Trace (trace)
type role Nom nominal
data Nom a = Nom Int deriving Show
class Gen g where
gen :: g
instance Gen (Nom a) where
gen = trace "genD" $ Nom 0
main = print (gen :: Nom Int) >> print (gen :: Nom ()) >> print (gen :: Nom Char)
```
This program shows that only one value of type Nom is created and shared, even though doing so requires coercing a nominal role
I discovered this while checking core for sharing after creating a constraint result caching mechanism. An IOref ended up being shared for multiple different constraint result holders
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| 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":"Optimizer Casting Caf with nominal type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":["coerce,","nominal"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When you make a function with a constant result, the optimizer will turn it into a cast of a CAF, even if doing so coerces a nominal parameter into a different one.\r\n\r\nMinimal Example program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE RoleAnnotations #-}\r\nimport Debug.Trace (trace)\r\ntype role Nom nominal\r\ndata Nom a = Nom Int deriving Show\r\nclass Gen g where\r\n gen :: g\r\ninstance Gen (Nom a) where\r\n gen = trace \"genD\" $ Nom 0\r\n\r\nmain = print (gen :: Nom Int) >> print (gen :: Nom ()) >> print (gen :: Nom Char)\r\n}}}\r\n\r\nThis program shows that only one value of type Nom is created and shared, even though doing so requires coercing a nominal role\r\n\r\nI discovered this while checking core for sharing after creating a constraint result caching mechanism. An IOref ended up being shared for multiple different constraint result holders","type_of_failure":"OtherFailure","blocking":[]} -->
https://gitlab.haskell.org/ghc/ghc/-/issues/14965
GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation;...
2019-07-07T18:14:52Z
blynn
GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails
A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.
See attached files. In one file I declared:
```hs
module Sep where
data Sep = Sep
{ bug...
A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.
See attached files. In one file I declared:
```hs
module Sep where
data Sep = Sep
{ bugVanishesWithoutThis :: [()]
, middle :: [String]
, orThis :: [()]
}
catSep :: Sep -> Sep -> Sep
catSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z)
cc :: Sep -> Bool
cc boost = elem "foo" $ middle boost
```
and in a second file, simple code fails when compiled with -O:
```hs
module Main (main) where
import Sep
main :: IO ()
main = print $ cc bb
bb :: Sep
bb = catSep b1 b2
b1 :: Sep
b1 = Sep [] ["foo"] []
b2 :: Sep
b2 = Sep [] ["bar"] []
```
This should print "True", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints "False" for GHC 8.4.1 with -O.
I was unable to reproduce the bug with a single file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ben@dfinity.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ben@dfinity.org"],"type":"Bug","description":"A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.\r\n\r\nSee attached files. In one file I declared:\r\n\r\n{{{#!hs\r\nmodule Sep where\r\n\r\ndata Sep = Sep\r\n { bugVanishesWithoutThis :: [()]\r\n , middle :: [String]\r\n , orThis :: [()]\r\n }\r\n\r\ncatSep :: Sep -> Sep -> Sep\r\ncatSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z)\r\n\r\ncc :: Sep -> Bool\r\ncc boost = elem \"foo\" $ middle boost\r\n}}}\r\n\r\nand in a second file, simple code fails when compiled with -O:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nimport Sep\r\n\r\nmain :: IO ()\r\nmain = print $ cc bb\r\n\r\nbb :: Sep\r\nbb = catSep b1 b2\r\n\r\nb1 :: Sep\r\nb1 = Sep [] [\"foo\"] []\r\n\r\nb2 :: Sep\r\nb2 = Sep [] [\"bar\"] []\r\n}}}\r\n\r\nThis should print \"True\", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints \"False\" for GHC 8.4.1 with -O.\r\n\r\nI was unable to reproduce the bug with a single file.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14927
Hyperbolic area sine is unstable for (even moderately) big negative arguments.
2019-07-07T18:15:01Z
leftaroundabout
Hyperbolic area sine is unstable for (even moderately) big negative arguments.
`asinh` is supposed to be the inverse of `sinh`, and this works pretty reliable for positive arguments. However, for negative arguments, the [currently used formula](http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Float.htm...
`asinh` is supposed to be the inverse of `sinh`, and this works pretty reliable for positive arguments. However, for negative arguments, the [currently used formula](http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Float.html#line-473)
```
asinh x = log (x + sqrt (1.0+x*x))
```
gets unstable much earlier than necessary, namely when the summands in the logarithm cancel almost to zero, dominated by the numerical error of the square root.
This is particularly troubling because mathematically \*\*a)\*\* `asinh` is a very “inert” function (i.e. you can carelessly put in huge numbers and – as long as they're not outright `Infinity` – always get a somewhat sane result), pseudo-sigmoidal as it were \*\*b)\*\* it is an *odd function*, fulfilling `asinh (-x) = -asinh x`.
Both is reflected in other implementations, e.g. Python, but not in GHC Haskell:
```
GHCi, version 8.2.1 Python 3.5.2 (default, Nov 23 2017, 16:37:01)
In [1]: from math import *
Prelude> asinh 1e6 In [2]: asinh(1e6)
14.50865773852447 Out[2]: 14.50865773852447
Prelude> asinh (-1e6) In [3]: asinh(-1e6)
-14.50865012405984 Out[3]: -14.50865773852447
Prelude> asinh 1e9 In [4]: asinh(1e9)
21.416413017506358 Out[4]: 21.416413017506354
Prelude> asinh (-1e9) In [5]: asinh(-1e9)
-Infinity Out[5]: -21.416413017506354
Prelude> asinh 1e76 In [6]: asinh(1e76)
175.6896142481074 Out[6]: 175.68961424810743
Prelude> asinh (-1e76) In [7]: asinh(-1e76)
-Infinity Out[7]: -175.68961424810743
```
Demo of non-inverse property:
```
Prelude> [(x, asinh $ sinh x) | x <- [-25..25]]
[(-25.0,-Infinity)
,(-24.0,-Infinity)
,(-23.0,-Infinity)
,(-22.0,-Infinity)
,(-21.0,-Infinity)
,(-20.0,-Infinity)
,(-19.0,-18.021826694558577)
,(-18.0,-18.021826694558577)
,(-17.0,-17.0102257828801)
,(-16.0,-15.998624871201619)
,(-15.0,-14.999878578873695)
,(-14.0,-13.999968823323222)
,(-13.0,-12.999991335176079)
,(-12.0,-12.000000137072186)
,(-11.0,-10.999999903206444)
,(-10.0,-10.000000013503529)
,(-9.0,-9.000000000551713)
,(-8.0,-8.00000000017109)
,(-7.0,-7.000000000036329)
,(-6.0,-5.999999999998066)
,(-5.0,-5.000000000000641)
,(-4.0,-4.000000000000046)
,(-3.0,-2.999999999999989)
,(-2.0,-1.9999999999999991)
,(-1.0,-1.0)
,(0.0,0.0)
,(1.0,1.0)
,(2.0,2.0)
,(3.0,3.0)
,(4.0,4.0)
,(5.0,5.0)
,(6.0,6.0)
,(7.0,7.0)
,(8.0,8.0)
,(9.0,9.0)
,(10.0,10.0)
,(11.0,11.0)
,(12.0,12.0)
,(13.0,13.0)
,(14.0,14.0)
,(15.0,15.0)
,(16.0,16.0)
,(17.0,17.0)
,(18.0,18.0)
,(19.0,19.0)
,(20.0,20.0)
,(21.0,21.0)
,(22.0,22.0)
,(23.0,23.0)
,(24.0,24.0)
,(25.0,25.0)]
```
Those results are less than satisfying, even for inputs that aren't astronomically big at all.
A simple fix would be to “copy” the sane positive-number behaviour to the negative side:
```
asinh x
| x < 0 = -asinh (-x)
| otherwise = log (x + sqrt (1.0+x*x))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hyperbolic area sine is unstable for (even moderately) big negative arguments.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`asinh` is supposed to be the inverse of `sinh`, and this works pretty reliable for positive arguments. However, for negative arguments, the [http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Float.html#line-473 currently used formula]\r\n{{{\r\nasinh x = log (x + sqrt (1.0+x*x))\r\n}}}\r\ngets unstable much earlier than necessary, namely when the summands in the logarithm cancel almost to zero, dominated by the numerical error of the square root.\r\n\r\nThis is particularly troubling because mathematically **a)** `asinh` is a very “inert” function (i.e. you can carelessly put in huge numbers and – as long as they're not outright `Infinity` – always get a somewhat sane result), pseudo-sigmoidal as it were **b)** it is an ''odd function'', fulfilling `asinh (-x) = -asinh x`.\r\n\r\nBoth is reflected in other implementations, e.g. Python, but not in GHC Haskell:\r\n{{{\r\nGHCi, version 8.2.1 Python 3.5.2 (default, Nov 23 2017, 16:37:01) \r\n\r\n In [1]: from math import *\r\n\r\nPrelude> asinh 1e6 In [2]: asinh(1e6)\r\n14.50865773852447 Out[2]: 14.50865773852447\r\n\r\nPrelude> asinh (-1e6) In [3]: asinh(-1e6)\r\n-14.50865012405984 Out[3]: -14.50865773852447\r\n\r\nPrelude> asinh 1e9 In [4]: asinh(1e9)\r\n21.416413017506358 Out[4]: 21.416413017506354\r\n\r\nPrelude> asinh (-1e9) In [5]: asinh(-1e9)\r\n-Infinity Out[5]: -21.416413017506354\r\n\r\nPrelude> asinh 1e76 In [6]: asinh(1e76)\r\n175.6896142481074 Out[6]: 175.68961424810743\r\n\r\nPrelude> asinh (-1e76) In [7]: asinh(-1e76)\r\n-Infinity Out[7]: -175.68961424810743\r\n}}}\r\n\r\nDemo of non-inverse property:\r\n{{{\r\nPrelude> [(x, asinh $ sinh x) | x <- [-25..25]]\r\n[(-25.0,-Infinity)\r\n,(-24.0,-Infinity)\r\n,(-23.0,-Infinity)\r\n,(-22.0,-Infinity)\r\n,(-21.0,-Infinity)\r\n,(-20.0,-Infinity)\r\n,(-19.0,-18.021826694558577)\r\n,(-18.0,-18.021826694558577)\r\n,(-17.0,-17.0102257828801)\r\n,(-16.0,-15.998624871201619)\r\n,(-15.0,-14.999878578873695)\r\n,(-14.0,-13.999968823323222)\r\n,(-13.0,-12.999991335176079)\r\n,(-12.0,-12.000000137072186)\r\n,(-11.0,-10.999999903206444)\r\n,(-10.0,-10.000000013503529)\r\n,(-9.0,-9.000000000551713)\r\n,(-8.0,-8.00000000017109)\r\n,(-7.0,-7.000000000036329)\r\n,(-6.0,-5.999999999998066)\r\n,(-5.0,-5.000000000000641)\r\n,(-4.0,-4.000000000000046)\r\n,(-3.0,-2.999999999999989)\r\n,(-2.0,-1.9999999999999991)\r\n,(-1.0,-1.0)\r\n,(0.0,0.0)\r\n,(1.0,1.0)\r\n,(2.0,2.0)\r\n,(3.0,3.0)\r\n,(4.0,4.0)\r\n,(5.0,5.0)\r\n,(6.0,6.0)\r\n,(7.0,7.0)\r\n,(8.0,8.0)\r\n,(9.0,9.0)\r\n,(10.0,10.0)\r\n,(11.0,11.0)\r\n,(12.0,12.0)\r\n,(13.0,13.0)\r\n,(14.0,14.0)\r\n,(15.0,15.0)\r\n,(16.0,16.0)\r\n,(17.0,17.0)\r\n,(18.0,18.0)\r\n,(19.0,19.0)\r\n,(20.0,20.0)\r\n,(21.0,21.0)\r\n,(22.0,22.0)\r\n,(23.0,23.0)\r\n,(24.0,24.0)\r\n,(25.0,25.0)]\r\n}}}\r\nThose results are less than satisfying, even for inputs that aren't astronomically big at all.\r\n\r\nA simple fix would be to “copy” the sane positive-number behaviour to the negative side:\r\n{{{\r\n asinh x\r\n | x < 0 = -asinh (-x)\r\n | otherwise = log (x + sqrt (1.0+x*x))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->
https://gitlab.haskell.org/ghc/ghc/-/issues/14925
Non-ASCII type names get garbled when their `TypeRep` is shown
2019-07-07T18:15:01Z
leftaroundabout
Non-ASCII type names get garbled when their `TypeRep` is shown
[Typeable](http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Typeable.html) allows easily showing the name of a type by, well, using `show` on it. However, this does not work right for types with Unicode symbols in their name:
...
[Typeable](http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Typeable.html) allows easily showing the name of a type by, well, using `show` on it. However, this does not work right for types with Unicode symbols in their name:
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Typeable
Prelude Data.Typeable> data W = W
Prelude Data.Typeable> typeOf W
W
Prelude Data.Typeable> data Ω = Ω
Prelude Data.Typeable> typeOf Ω
Ω
```
This did not yet happen in GHC-7:
```
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Typeable
Prelude Data.Typeable> data W = W
Prelude Data.Typeable> typeOf W
W
Prelude Data.Typeable> data Ω = Ω
Prelude Data.Typeable> typeOf Ω
Ω
```
N.b.:
```
Prelude> import Data.ByteString.Char8 as BC8
Prelude BC8> BC8.putStrLn $ pack "Ω"
Ω
```
So, this appears to be a UTF-8 problem – something interprets bytestring-stored type-representation names as a different character encoding.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Non-ASCII type names get garbled when their `TypeRep` is shown","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["ASCII","TypeRep","Typeable","UTF-8","Unicode"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"[http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Typeable.html Typeable] allows easily showing the name of a type by, well, using `show` on it. However, this does not work right for types with Unicode symbols in their name:\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :m +Data.Typeable\r\nPrelude Data.Typeable> data W = W\r\nPrelude Data.Typeable> typeOf W\r\nW\r\nPrelude Data.Typeable> data Ω = Ω\r\nPrelude Data.Typeable> typeOf Ω\r\nΩ\r\n}}}\r\nThis did not yet happen in GHC-7:\r\n{{{\r\nGHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :m +Data.Typeable\r\nPrelude Data.Typeable> data W = W\r\nPrelude Data.Typeable> typeOf W\r\nW\r\nPrelude Data.Typeable> data Ω = Ω\r\nPrelude Data.Typeable> typeOf Ω\r\nΩ\r\n}}}\r\nN.b.:\r\n{{{\r\nPrelude> import Data.ByteString.Char8 as BC8\r\nPrelude BC8> BC8.putStrLn $ pack \"Ω\"\r\nΩ\r\n}}}\r\nSo, this appears to be a UTF-8 problem – something interprets bytestring-stored type-representation names as a different character encoding.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14918
GHC 8.4.1 regression: derived Read instances with field names containing # no...
2019-07-07T18:15:03Z
Ryan Scott
GHC 8.4.1 regression: derived Read instances with field names containing # no longer parse
(Originally noticed [here](https://github.com/ekmett/transformers-compat/issues/32).)
Consider the following program:
```hs
{-# LANGUAGE MagicHash #-}
module Bug where
data T a = MkT { runT# :: a }
deriving (Read, Show)
t1, t2 :: T...
(Originally noticed [here](https://github.com/ekmett/transformers-compat/issues/32).)
Consider the following program:
```hs
{-# LANGUAGE MagicHash #-}
module Bug where
data T a = MkT { runT# :: a }
deriving (Read, Show)
t1, t2 :: T Int
t1 = MkT 1
t2 = read $ show t1
main :: IO ()
main = print t2
```
In GHC 8.2.1, this runs without issue:
```
$ /opt/ghc/8.2.2/bin/runghc Bug.hs
MkT {runT# = 1}
```
In GHC 8.4.1, however, this produces a runtime error:
```
$ ~/Software/ghc-8.4.1/bin/runghc Bug.hs
Bug.hs: Prelude.read: no parse
```
8.4.2