GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-01-16T09:37:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13634num009 fails on POWER82022-01-16T09:37:43ZPeter Trommlerptrommler@acm.orgnum009 fails on POWER8This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running op...This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"num009 fails on POWER8","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd","hvr"],"type":"Bug","description":"This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:\r\n{{{\r\n+uh oh! tanf 1.5707964\r\n+-2.2877334e7\r\n+-2.2877332e7\r\n+(-11438667,1)\r\n+(-11438666,1)\r\n Done\r\n}}}\r\n\r\nThe test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13631In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone2019-07-07T18:20:51ZvantoIn GHCi a result is wrong when -fdefer-typed-holes is used with underscore aloneI open this ticket instead of `#13579` to restate it and I closed the other.\\\\
In fact a result of the compiler which I think is wrong misled me.\\\\
Therefore I close tickets `#13602` and `#13557`.\\\\
In Haskell2010 Language Report i...I open this ticket instead of `#13579` to restate it and I closed the other.\\\\
In fact a result of the compiler which I think is wrong misled me.\\\\
Therefore I close tickets `#13602` and `#13557`.\\\\
In Haskell2010 Language Report it is said that :\\\\
1. underscore "_ " all by itself is a reserved identifier.\\\\
1. underscore "_" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\\\
So `_e` is an identifier like `__`\\\\
GHCi gives a bad result when he computed the code below.\\\\
```
Prelude> :set -fdefer-typed-holes
Prelude> let f = map (\x -> True) [_, _]
<interactive>:2:27: warning: [-Wtyped-holes]
* Found hole: _ :: a0
Where: `a0' is an ambiguous type variable
* In the expression: _
In the second argument of `map', namely `[_, _]'
In the expression: map (\ x -> True) [_, _]
* Relevant bindings include
f :: [Bool] (bound at <interactive>:2:5)
<interactive>:2:30: warning: [-Wtyped-holes]
* Found hole: _ :: a0
Where: `a0' is an ambiguous type variable
* In the expression: _
In the second argument of `map', namely `[_, _]'
In the expression: map (\ x -> True) [_, _]
* Relevant bindings include
f :: [Bool] (bound at <interactive>:2:5)
Prelude> f
[True,True]
```
The underscore "_" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\\\
This is the bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I open this ticket instead of {{{#13579}}} to restate it and I closed the other.\\\\\r\nIn fact a result of the compiler which I think is wrong misled me.\\\\\r\nTherefore I close tickets {{{#13602}}} and {{{#13557}}}.\\\\\r\nIn Haskell2010 Language Report it is said that :\\\\\r\n1. underscore \"_ \" all by itself is a reserved identifier.\\\\\r\n2. underscore \"_\" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\\\\r\nSo {{{_e}}} is an identifier like {{{__}}}\\\\\r\n\r\nGHCi gives a bad result when he computed the code below.\\\\\r\n\r\n\r\n{{{\r\nPrelude> :set -fdefer-typed-holes\r\nPrelude> let f = map (\\x -> True) [_, _]\r\n\r\n<interactive>:2:27: warning: [-Wtyped-holes]\r\n * Found hole: _ :: a0\r\n Where: `a0' is an ambiguous type variable\r\n * In the expression: _\r\n In the second argument of `map', namely `[_, _]'\r\n In the expression: map (\\ x -> True) [_, _]\r\n * Relevant bindings include\r\n f :: [Bool] (bound at <interactive>:2:5)\r\n\r\n<interactive>:2:30: warning: [-Wtyped-holes]\r\n * Found hole: _ :: a0\r\n Where: `a0' is an ambiguous type variable\r\n * In the expression: _\r\n In the second argument of `map', namely `[_, _]'\r\n In the expression: map (\\ x -> True) [_, _]\r\n * Relevant bindings include\r\n f :: [Bool] (bound at <interactive>:2:5)\r\nPrelude> f\r\n[True,True]\r\n}}}\r\nThe underscore \"_\" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\\\\r\nThis is the bug.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13593Unexpected behavior from Data.List.groupBy2019-07-07T18:21:07ZdsfUnexpected behavior from Data.List.groupByI was hoping that
```hs
let notBoth1 a b = not (a == 1 && b == 1) in
groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1]
```
would give me
```
[[1],[1,2,3,1],[1,4,5,6,1]]
```
but instead I get
```
[[1],[1,2,3],[1],[1,4,5,6],[1]]
```
It seems t...I was hoping that
```hs
let notBoth1 a b = not (a == 1 && b == 1) in
groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1]
```
would give me
```
[[1],[1,2,3,1],[1,4,5,6,1]]
```
but instead I get
```
[[1],[1,2,3],[1],[1,4,5,6],[1]]
```
It seems that groupBy assumes transitivity in the argument function. I have a new implementation that does not make this assumption. Of course, the implications of changing this function's behavior are troubling.
```hs
groupBy' :: (a -> a -> Bool) -> [a] -> [[a]]
groupBy' p (x : xs) = go [x] xs
where
go (x : xs) (y : zs) | p x y = go (y : x : xs) zs
go g (y : zs) = reverse g : go [y] zs
go g [] = [reverse g]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpected behavior from Data.List.groupBy","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was hoping that\r\n{{{#!hs\r\nlet notBoth1 a b = not (a == 1 && b == 1) in\r\ngroupBy notBoth1 [1,1,2,3,1,1,4,5,6,1]\r\n}}}\r\nwould give me\r\n{{{\r\n[[1],[1,2,3,1],[1,4,5,6,1]]\r\n}}}\r\nbut instead I get\r\n{{{\r\n[[1],[1,2,3],[1],[1,4,5,6],[1]]\r\n}}}\r\nIt seems that groupBy assumes transitivity in the argument function. I have a new implementation that does not make this assumption. Of course, the implications of changing this function's behavior are troubling.\r\n{{{#!hs\r\ngroupBy' :: (a -> a -> Bool) -> [a] -> [[a]]\r\ngroupBy' p (x : xs) = go [x] xs\r\n where\r\n go (x : xs) (y : zs) | p x y = go (y : x : xs) zs\r\n go g (y : zs) = reverse g : go [y] zs\r\n go g [] = [reverse g]\r\n}}}","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->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/13552Enum Float/Double does not match Haskell Report2019-07-07T18:21:22ZLukeEnum Float/Double does not match Haskell ReportSection 6.3.4 of the report says that the `Enum` instance for `Float` and
`Double` should define the `enumFromThen*` functions such that
`enumFromThen e1 e2` is the list `[e1, e1 + i, e1 + 2i, ...]`
where `i = e2 - e1`. The actual implem...Section 6.3.4 of the report says that the `Enum` instance for `Float` and
`Double` should define the `enumFromThen*` functions such that
`enumFromThen e1 e2` is the list `[e1, e1 + i, e1 + 2i, ...]`
where `i = e2 - e1`. The actual implementation in base is that of successive
additions (which is approximately the same thing for some types).
Successive additions causes issues with floating point rounding. Changing the definition to something like
```hs
enumFromThen_ e1 e2 = let i = e2 - e1 in map (\n -> e1 + n * i) [0..]
```
significantly improves the accuracy of floating point ranges, as well
as \*\*matching what the report says\*\*.
```
Prelude> last $ take 101 $ [0,0.1..] :: Float
10.000028
Prelude> last $ take 101 $ enumFromThen_ 0 0.1 :: Float
10.0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"Enum Float/Double does not match Haskell Report","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Section 6.3.4 of the report says that the `Enum` instance for `Float` and\r\n`Double` should define the `enumFromThen*` functions such that\r\n`enumFromThen e1 e2` is the list `[e1, e1 + i, e1 + 2i, ...]`\r\nwhere `i = e2 - e1`. The actual implementation in base is that of successive\r\nadditions (which is approximately the same thing for some types).\r\n\r\nSuccessive additions causes issues with floating point rounding. Changing the definition to something like\r\n\r\n{{{#!hs\r\nenumFromThen_ e1 e2 = let i = e2 - e1 in map (\\n -> e1 + n * i) [0..]\r\n}}}\r\n\r\nsignificantly improves the accuracy of floating point ranges, as well\r\nas **matching what the report says**.\r\n\r\n{{{\r\nPrelude> last $ take 101 $ [0,0.1..] :: Float\r\n10.000028\r\n\r\nPrelude> last $ take 101 $ enumFromThen_ 0 0.1 :: Float\r\n10.0\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13052unsafePerformIO duped on multithread if within the same IO thunk2019-07-07T18:23:55ZgelisamunsafePerformIO duped on multithread if within the same IO thunkUnlike `unsafeDupablePerformIO`, an `unsafePerformIO` block is not supposed to be executed more than once when two threads race to evaluate it, and yet the following program detects that the counter is sometimes incremented twice:
```hs...Unlike `unsafeDupablePerformIO`, an `unsafePerformIO` block is not supposed to be executed more than once when two threads race to evaluate it, and yet the following program detects that the counter is sometimes incremented twice:
```hs
{-# LANGUAGE BangPatterns #-}
{-# OPTIONS -O0 -threaded -rtsopts -with-rtsopts=-N #-}
module Main where
import Control.Concurrent
import System.IO.Unsafe
runThreads :: IO () -> IO () -> IO ()
runThreads body1 body2 = do
var1 <- newEmptyMVar
var2 <- newEmptyMVar
_ <- forkIO $ do { !_ <- body1; putMVar var1 () }
_ <- forkIO $ do { !_ <- body2; putMVar var2 () }
takeMVar var1
takeMVar var2
main :: IO ()
main = do
counter <- newMVar (0 :: Int)
let sharedThunk = unsafePerformIO
$ modifyMVar_ counter (return . (+1))
let sharedIO = return sharedThunk
_ <- runThreads sharedIO sharedIO
n <- takeMVar counter
if n == 1 then main else print n
```
Note that optimizations are turned off, so this isn't due to inlining. In fact, if I inline `sharedIO` and write
```hs
_ <- runThreads (return sharedThunk) (return sharedThunk)
```
instead, the problem disappears. So it seems that in order to reproduce the problem, two threads must race to evaluate an IO thunk containing an `unsafePerformIO` block; a race to evaluate the `unsafePerformIO` block is not sufficient.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2-rc2 |
| 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":"unsafePerformIO duped on multithread if within the same IO thunk","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Unlike `unsafeDupablePerformIO`, an `unsafePerformIO` block is not supposed to be executed more than once when two threads race to evaluate it, and yet the following program detects that the counter is sometimes incremented twice:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\n{-# OPTIONS -O0 -threaded -rtsopts -with-rtsopts=-N #-}\r\nmodule Main where\r\nimport Control.Concurrent\r\nimport System.IO.Unsafe\r\n\r\nrunThreads :: IO () -> IO () -> IO ()\r\nrunThreads body1 body2 = do\r\n var1 <- newEmptyMVar\r\n var2 <- newEmptyMVar\r\n _ <- forkIO $ do { !_ <- body1; putMVar var1 () }\r\n _ <- forkIO $ do { !_ <- body2; putMVar var2 () }\r\n takeMVar var1\r\n takeMVar var2\r\n\r\nmain :: IO ()\r\nmain = do\r\n counter <- newMVar (0 :: Int)\r\n let sharedThunk = unsafePerformIO\r\n $ modifyMVar_ counter (return . (+1))\r\n let sharedIO = return sharedThunk\r\n _ <- runThreads sharedIO sharedIO\r\n n <- takeMVar counter\r\n if n == 1 then main else print n\r\n}}}\r\n\r\nNote that optimizations are turned off, so this isn't due to inlining. In fact, if I inline `sharedIO` and write\r\n\r\n{{{#!hs\r\n _ <- runThreads (return sharedThunk) (return sharedThunk)\r\n}}}\r\n\r\ninstead, the problem disappears. So it seems that in order to reproduce the problem, two threads must race to evaluate an IO thunk containing an `unsafePerformIO` block; a race to evaluate the `unsafePerformIO` block is not sufficient.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13007ghc-options -threaded present but -N option unrecognised on ARM2019-07-07T18:24:08Ztmpzghc-options -threaded present but -N option unrecognised on ARMWhen compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options
```
-threaded -rtsopts -with-rtsopts=-N
```
However when running the program with -N, -N is not a recognised opt...When compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options
```
-threaded -rtsopts -with-rtsopts=-N
```
However when running the program with -N, -N is not a recognised option. See output here http://pastebin.com/sKjfkRtq
Running with --info gives the following http://pastebin.com/q36Ef7y4 showing that ("RTS way", "rts_thr") is available.
Investigation already done here: https://www.reddit.com/r/haskell/comments/5j0u36/getting_haskell_and_stack_on_a_rapsberry_pi_3/dbcgbht/
Steps used to get ghc on the system: http://allocinit.io/haskell/haskell-on-raspberry-pi-3/
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-options -threaded present but -N option unrecognised on ARM","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["arm,","raspberrypi,","raspbian,","rts,","threaded"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options\r\n\r\n{{{\r\n-threaded -rtsopts -with-rtsopts=-N\r\n}}}\r\n\r\nHowever when running the program with -N, -N is not a recognised option. See output here http://pastebin.com/sKjfkRtq\r\n\r\nRunning with --info gives the following http://pastebin.com/q36Ef7y4 showing that (\"RTS way\", \"rts_thr\") is available.\r\n\r\nInvestigation already done here: https://www.reddit.com/r/haskell/comments/5j0u36/getting_haskell_and_stack_on_a_rapsberry_pi_3/dbcgbht/\r\n\r\nSteps used to get ghc on the system: http://allocinit.io/haskell/haskell-on-raspberry-pi-3/","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12869getChar doesn't work on a new Windows build2020-07-27T06:37:37ZDarwin226getChar doesn't work on a new Windows buildLast night I updated my PC to the 14965 Windows insider build. Today I notice that `getLine` no longer terminates (pressing enter just goes to a new line), but I'm suspecting that the root cause it that `getChar` returns `'\NUL'` no math...Last night I updated my PC to the 14965 Windows insider build. Today I notice that `getLine` no longer terminates (pressing enter just goes to a new line), but I'm suspecting that the root cause it that `getChar` returns `'\NUL'` no mather what is input.
I've tried this both GHCi and in a compiled program.
This is only broken if I set my codepage to 65001 (UTF-8). If I set it to something like 850 it works as it should.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getChar doesn't work on a new Windows build","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Last night I updated my PC to the 14965 Windows insider build. Today I notice that `getLine` no longer terminates (pressing enter just goes to a new line), but I'm suspecting that the root cause it that `getChar` returns `'\\NUL'` no mather what is input.\r\n\r\nI've tried this both GHCi and in a compiled program.\r\n\r\nThis is only broken if I set my codepage to 65001 (UTF-8). If I set it to something like 850 it works as it should.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12750hGetContents leads to late/silent failures2019-07-07T18:25:18Zmassimo.zanibonihGetContents leads to late/silent failuresI have the same problem described in the closed ticket #9236
This is a test-case https://github.com/massimo-zaniboni/ghc_lazy_file_content_error
I tried with ghc 7.10.3 and 8.0.1
<details><summary>Trac metadata</summary>
| Trac field...I have the same problem described in the closed ticket #9236
This is a test-case https://github.com/massimo-zaniboni/ghc_lazy_file_content_error
I tried with ghc 7.10.3 and 8.0.1
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, massimo.zaniboni |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hGetContents leads to late/silent failures","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","massimo.zaniboni"],"type":"Bug","description":"I have the same problem described in the closed ticket #9236\r\n\r\nThis is a test-case https://github.com/massimo-zaniboni/ghc_lazy_file_content_error\r\n\r\nI tried with ghc 7.10.3 and 8.0.1\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12736Calling a complex Haskell function (obtained via FFI wrapper function) from M...2019-07-07T18:25:21ZbavismCalling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modifiedAccording to the [MSDN](https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx), in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer vi...According to the [MSDN](https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx), in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail.
I can reproduce this error in [this project](https://github.com/bavis-m/raycast), which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window).
The output on every frame showing the view matrix should be:
```
viewM: 0.003125 0.000000 0.000000 -1.000000
0.000000 0.004167 0.000000 -1.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000
```
Running the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different.
I have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code.
Instructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["ffi,registers,sse2,clobber,xmm"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the [https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx MSDN], in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail.\r\n\r\nI can reproduce this error in [https://github.com/bavis-m/raycast this project], which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window).\r\n\r\nThe output on every frame showing the view matrix should be:\r\n{{{\r\nviewM: 0.003125 0.000000 0.000000 -1.000000\r\n 0.000000 0.004167 0.000000 -1.000000\r\n 0.000000 0.000000 1.000000 0.000000\r\n 0.000000 0.000000 0.000000 1.000000\r\n}}}\r\n\r\nRunning the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different.\r\n\r\nI have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code.\r\n\r\nInstructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12678-threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHC2019-07-07T18:25:36Zenolan-threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHCHi GHC folks.
In section 6.1.2.2 of the user's guide it says "Only dynamic flags can be used in an OPTIONS_GHC pragma" and in section 6.6 it says `-threaded` is a dynamic flag. However, the following program compiles successfully but do...Hi GHC folks.
In section 6.1.2.2 of the user's guide it says "Only dynamic flags can be used in an OPTIONS_GHC pragma" and in section 6.6 it says `-threaded` is a dynamic flag. However, the following program compiles successfully but doesn't get linked with the threaded RTS unless I add the option on the command line:
```hs
{-# OPTIONS_GHC -threaded #-}
main = return ()
```
Running `./foo +RTS --info` reports `("RTS way", "rts_v")` when it should say `rts_thr`.
Either `-threaded` should be settable in `OPTIONS_GHC` pragmas, or setting it should be an error that aborts compilation. The documentation should accurately state the rules regardless.
This happens on 8.0.1, 7.10.3 and the `ghc-8.0` branch. I didn't check master.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"-threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi GHC folks.\r\n\r\nIn section 6.1.2.2 of the user's guide it says \"Only dynamic flags can be used in an OPTIONS_GHC pragma\" and in section 6.6 it says `-threaded` is a dynamic flag. However, the following program compiles successfully but doesn't get linked with the threaded RTS unless I add the option on the command line:\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -threaded #-}\r\n\r\nmain = return ()\r\n}}}\r\n\r\nRunning `./foo +RTS --info` reports `(\"RTS way\", \"rts_v\")` when it should say `rts_thr`.\r\n\r\nEither `-threaded` should be settable in `OPTIONS_GHC` pragmas, or setting it should be an error that aborts compilation. The documentation should accurately state the rules regardless.\r\n\r\nThis happens on 8.0.1, 7.10.3 and the `ghc-8.0` branch. I didn't check master.","type_of_failure":"OtherFailure","blocking":[]} -->https://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/12556`stimes` adds extra power to Semigroup2019-07-07T18:26:07ZIcelandjack`stimes` adds extra power to Semigroup```
ghci> stimes 0 (undefined :: [_])
[]
ghci> stimes 0 undefined
()
```
makes it seem like `stimes 0` has some knowledge about `mempty` from `Monoid` but it has the following type
```hs
stimes 0 :: Semigroup a => a -> a
```
Desired ...```
ghci> stimes 0 (undefined :: [_])
[]
ghci> stimes 0 undefined
()
```
makes it seem like `stimes 0` has some knowledge about `mempty` from `Monoid` but it has the following type
```hs
stimes 0 :: Semigroup a => a -> a
```
Desired behaviour? Given that type (assuming it only has the power of `<>`) I would have assumed this behaviour
```
ghci> data L a = N | C a (L a) deriving Show
ghci> instance Semigroup (L a) where (<>) = undefined
ghci|
ghci> stimes 0 (undefined :: L _)
*** Exception: stimes: positive multiplier expected
```https://gitlab.haskell.org/ghc/ghc/-/issues/12377getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS...2022-07-24T07:02:04ZoherralagetExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv\[0\] to determine path and argv\[0\] might not be absolute path.
My environment:
```
$ uname -...System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv\[0\] to determine path and argv\[0\] might not be absolute path.
My environment:
```
$ uname -a
OpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64
$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.3
```
This test program in OpenBSD:
```hs
module Main where
import System.Environment
main = getExecutablePath >>= print
```
returns
```
$ ./test
"./test"
```
For example in OS X the call returns absolute path:
```
$ ./test
"/Users/oherrala/tmp/test"
```
OpenBSD is one of the operating systems which gets fall back to using argv\[0\] to determine exec's location:
https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environment/ExecutablePath.hsc\#l152
Maybe the argv\[0\] result should be wrapped with realpath(3) to get absolute path?
This bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512\#issuecomment-231604356
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv[0] to determine path and argv[0] might not be absolute path.\r\n\r\nMy environment:\r\n\r\n{{{\r\n$ uname -a\r\nOpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64\r\n$ ghc -V\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.3\r\n}}}\r\n\r\nThis test program in OpenBSD:\r\n\r\n{{{#!hs\r\nmodule Main where\r\nimport System.Environment\r\nmain = getExecutablePath >>= print\r\n}}}\r\n\r\nreturns\r\n\r\n{{{\r\n$ ./test\r\n\"./test\"\r\n}}}\r\n\r\nFor example in OS X the call returns absolute path:\r\n\r\n{{{\r\n$ ./test\r\n\"/Users/oherrala/tmp/test\"\r\n}}}\r\n\r\nOpenBSD is one of the operating systems which gets fall back to using argv[0] to determine exec's location:\r\n\r\nhttps://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environment/ExecutablePath.hsc#l152\r\n\r\nMaybe the argv[0] result should be wrapped with realpath(3) to get absolute path?\r\n\r\n\r\nThis bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512#issuecomment-231604356\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12167<<loop>> when zip + unzipping a shadowed Vector type variable2019-07-07T18:27:22Zmarkog<<loop>> when zip + unzipping a shadowed Vector type variable```hs
module Main where
import Data.Vector.Unboxed (Vector)
import qualified Data.Vector.Unboxed as V
(|>) :: a -> (a -> b) -> b
x |> f = f x
main = do
s <- do
x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)
...```hs
module Main where
import Data.Vector.Unboxed (Vector)
import qualified Data.Vector.Unboxed as V
(|>) :: a -> (a -> b) -> b
x |> f = f x
main = do
s <- do
x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)
d <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)
let
xd :: (Vector Int, Vector Int)
xd =
V.zip x d
|> V.unzip
(x,d) = xd -- here is where the error happens
-- returning xd works
-- removing the shadowing also works
in return x
print s
```
I do not see how the above code warrants a \<\<loop\>\> error as there is really no recursion in it. The linter always complains when I shadow variables, but I often use the above style in F\# to reduce the namespace bloat. Shadowing is not a problem when the variables have different types.
Is the above really a compiler error?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| 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":"<<loop>> when zip + unzipping a shadowed Vector type variable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nmodule Main where\r\n import Data.Vector.Unboxed (Vector)\r\n import qualified Data.Vector.Unboxed as V\r\n\r\n (|>) :: a -> (a -> b) -> b\r\n x |> f = f x\r\n\r\n main = do\r\n s <- do\r\n x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)\r\n d <- return $ V.fromList [1,2,3,4] :: IO (Vector Int)\r\n let\r\n xd :: (Vector Int, Vector Int)\r\n xd =\r\n V.zip x d\r\n |> V.unzip\r\n (x,d) = xd -- here is where the error happens\r\n -- returning xd works\r\n -- removing the shadowing also works\r\n in return x\r\n print s\r\n}}}\r\n\r\nI do not see how the above code warrants a <<loop>> error as there is really no recursion in it. The linter always complains when I shadow variables, but I often use the above style in F# to reduce the namespace bloat. Shadowing is not a problem when the variables have different types.\r\n\r\nIs the above really a compiler error?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11997hSetFileSize zeroes file2019-07-07T18:28:04ZjaceredahSetFileSize zeroes fileThe following sequence:
```
cp /bin/echo /tmp/echo && ghc -e 'import System.IO' -e 'withFile "/tmp/echo" WriteMode (`hSetFileSize` 1000)'
```
results in /tmp/echo containing 1000 zeros. I would expect the truncated content as if trunca...The following sequence:
```
cp /bin/echo /tmp/echo && ghc -e 'import System.IO' -e 'withFile "/tmp/echo" WriteMode (`hSetFileSize` 1000)'
```
results in /tmp/echo containing 1000 zeros. I would expect the truncated content as if truncate() was called.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| 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":"hSetFileSize zeroes file","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following sequence:\r\n\r\n\r\n{{{\r\ncp /bin/echo /tmp/echo && ghc -e 'import System.IO' -e 'withFile \"/tmp/echo\" WriteMode (`hSetFileSize` 1000)'\r\n}}}\r\n\r\nresults in /tmp/echo containing 1000 zeros. I would expect the truncated content as if truncate() was called.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11683compiled files don't load in ghci2019-07-07T18:29:06Zgeorge.colpittscompiled files don't load in ghcicompiled files don't load in ghci
```
ghc -DYNAMIC bug.hs
[1 of 1] Compiling Main ( bug.hs, bug.o )
Linking bug ...
bash-3.2$ ghci -ignore-dot-ghci
GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help
Prel...compiled files don't load in ghci
```
ghc -DYNAMIC bug.hs
[1 of 1] Compiling Main ( bug.hs, bug.o )
Linking bug ...
bash-3.2$ ghci -ignore-dot-ghci
GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help
Prelude> Prelude> :load bug
[1 of 1] Compiling Main ( bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> :show modules
Main ( bug.hs, interpreted )
*Main>
```
According to the doc, file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html\#loading-compiled-code, this should work:
```
Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code (if you are on a platform that supports it), and so in order to use compiled code with GHCi it must be compiled for dynamic linking.
```
Similarly #8736\##11683 says the same thing:
```
if you say :load Foo in GHCi
Foo was compiled with -dynamic: loads Foo.o
```
Interestingly -fobject-code does work:
```
ghci -ignore-dot-ghci -fobject-code
GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help
Prelude> :load bug
[1 of 1] Compiling Main ( bug.hs, bug.o )
Ok, modules loaded: Main.
Prelude Main>
```
Unfortunately when I add -v I don't see why it works.
```
ghci -v -ignore-dot-ghci -fobject-code
```
It doesn't seem to use just ghc to compile , it also uses gcc, see attached file.
```
ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
bash-3.2$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv -fno-builtin")
,("C compiler command","/usr/bin/gcc")
,("C compiler flags"," -m64 -fno-stack-protector")
,("C compiler link flags"," -m64")
,("Haskell CPP command","/usr/bin/gcc")
,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs")
,("ld command","/usr/bin/ld")
,("ld flags"," -arch x86_64")
,("ld supports compact unwind","YES")
,("ld supports build-id","NO")
,("ld supports filelist","YES")
,("ld is GNU ld","NO")
,("ar command","/usr/bin/ar")
,("ar flags","clqs")
,("ar supports at file","NO")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("libtool command","libtool")
,("perl command","/usr/bin/perl")
,("cross compiling","NO")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has .ident directive","True")
,("target has subsections via symbols","True")
,("Unregisterised","NO")
,("LLVM llc command","/usr/local/bin/llc-3.7")
,("LLVM opt command","/usr/local/bin/opt-3.7")
,("Project version","8.0.0.20160204")
,("Project Git commit id","e2230228906a1c0fa1f86a0c1aa18d87de3cc49d")
,("Booter version","7.10.2")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
,("RTS expects libdw","NO")
,("Support dynamic-too","YES")
,("Support parallel --make","YES")
,("Support reexported-modules","YES")
,("Support thinning and renaming package flags","YES")
,("Requires unified installed package IDs","YES")
,("Uses package keys","YES")
,("Uses unit IDs","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","YES")
,("GHC Profiled","NO")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/lib/ghc-8.0.0.20160204")
,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160204/package.conf.d")
]
```https://gitlab.haskell.org/ghc/ghc/-/issues/11628Unexpected results with Read/Show2019-07-07T18:29:25ZEric CrockettUnexpected results with Read/ShowIn the following simplified example, `Foo` and `U` correspond to GADTs that GHC will not derive `Read`/`Show` for. I attempted to work around that by using newtypes for each GADT constructor, and letting GHC derive the `Show`/`Read` inst...In the following simplified example, `Foo` and `U` correspond to GADTs that GHC will not derive `Read`/`Show` for. I attempted to work around that by using newtypes for each GADT constructor, and letting GHC derive the `Show`/`Read` instances for those instead. However, I get a runtime error (`Prelude.read: no parse`) on the second print statement in `main`:
```
{-# LANGUAGE FlexibleContexts, FlexibleInstances, GADTs, ScopedTypeVariables #-}
import Text.Read (Read(readPrec))
newtype Bar r = Bar r deriving (Show, Read)
newtype Foo r = Foo (Bar r)
-- use the GHC-derived Show/Read for Bar
instance (Show r) => Show (Foo r) where
show (Foo x) = show x
instance (Read r) => Read (Foo r) where
readPrec = Foo <$> readPrec
data U t rep r where
U1 :: t r -> U t Int r
U2 :: t r -> U t Char r
-- use the Read/Show instances for U1Wrap and U2Wrap
newtype U1Wrap t r = U1Wrap {unU1Wrap :: t r} deriving (Show, Read)
newtype U2Wrap t r = U2Wrap (t r) deriving (Show, Read)
instance (Read (t r)) => Read (U t Int r) where
readPrec = (U1 . unU1Wrap) <$> readPrec
instance (Read (U2Wrap t r)) => Read (U t Char r) where
readPrec = do
x <- readPrec
return $ case x of
(U2Wrap y) -> U2 y
instance (Show (t r)) => Show (U t Int r) where
show (U1 x) = show $ U1Wrap x
instance (Show (t r)) => Show (U t Char r) where
show (U2 x) = show (U2Wrap x :: U2Wrap t r)
main :: IO ()
main = do
let x = U1 $ Foo $ Bar 3
y = U2 $ Foo $ Bar 3
print $ show (read (show x) `asTypeOf` x)
print $ show (read (show y) `asTypeOf` y)
```
Someone mentioned that I should define `showsPrec` rather than `show`, but these are listed as alternatives in [the docs](https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0/Text-Show.html).
It's not clear to me if GHCs derived instances are invalid, or if I'm doing something illegal. In the latter case, the docs need some improvement.
(Verified this behavior in 7.10.2 and HEAD.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.10.3 |
| 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":"Unexpected results with Read/Show","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following simplified example, `Foo` and `U` correspond to GADTs that GHC will not derive `Read`/`Show` for. I attempted to work around that by using newtypes for each GADT constructor, and letting GHC derive the `Show`/`Read` instances for those instead. However, I get a runtime error (`Prelude.read: no parse`) on the second print statement in `main`:\r\n\r\n{{{\r\n{-# LANGUAGE FlexibleContexts, FlexibleInstances, GADTs, ScopedTypeVariables #-}\r\n\r\nimport Text.Read (Read(readPrec))\r\n\r\nnewtype Bar r = Bar r deriving (Show, Read)\r\nnewtype Foo r = Foo (Bar r)\r\n-- use the GHC-derived Show/Read for Bar\r\ninstance (Show r) => Show (Foo r) where\r\n show (Foo x) = show x\r\ninstance (Read r) => Read (Foo r) where\r\n readPrec = Foo <$> readPrec\r\n\r\ndata U t rep r where\r\n U1 :: t r -> U t Int r\r\n U2 :: t r -> U t Char r\r\n-- use the Read/Show instances for U1Wrap and U2Wrap\r\nnewtype U1Wrap t r = U1Wrap {unU1Wrap :: t r} deriving (Show, Read)\r\nnewtype U2Wrap t r = U2Wrap (t r) deriving (Show, Read)\r\ninstance (Read (t r)) => Read (U t Int r) where\r\n readPrec = (U1 . unU1Wrap) <$> readPrec\r\ninstance (Read (U2Wrap t r)) => Read (U t Char r) where\r\n readPrec = do\r\n x <- readPrec\r\n return $ case x of\r\n (U2Wrap y) -> U2 y\r\ninstance (Show (t r)) => Show (U t Int r) where\r\n show (U1 x) = show $ U1Wrap x\r\ninstance (Show (t r)) => Show (U t Char r) where\r\n show (U2 x) = show (U2Wrap x :: U2Wrap t r)\r\n\r\nmain :: IO ()\r\nmain = do\r\n let x = U1 $ Foo $ Bar 3\r\n y = U2 $ Foo $ Bar 3\r\n print $ show (read (show x) `asTypeOf` x)\r\n print $ show (read (show y) `asTypeOf` y)\r\n}}}\r\n\r\nSomeone mentioned that I should define `showsPrec` rather than `show`, but these are listed as alternatives in [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0/Text-Show.html the docs].\r\n\r\nIt's not clear to me if GHCs derived instances are invalid, or if I'm doing something illegal. In the latter case, the docs need some improvement.\r\n\r\n(Verified this behavior in 7.10.2 and HEAD.)","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11553`round (± ∞ :: Double)` not infinite2019-07-07T18:29:51ZHerbert Valerio Riedelhvr@gnu.org`round (± ∞ :: Double)` not infiniteRounding 1/0 or -1/0 results in an arbitrary chosen `Integer` value, e.g.
```
λ:2> (round (1/0 :: Double) :: Integer) == 2^1024
True
λ:3> (round (-1/0 :: Double) :: Integer) == -(2^1024)
True
λ:4> (round (0/0 :: Double) :: Integer) ...Rounding 1/0 or -1/0 results in an arbitrary chosen `Integer` value, e.g.
```
λ:2> (round (1/0 :: Double) :: Integer) == 2^1024
True
λ:3> (round (-1/0 :: Double) :: Integer) == -(2^1024)
True
λ:4> (round (0/0 :: Double) :: Integer) == -(2^1024 + 2^1023)
True
```
I'm not sure if this is more desirable than returning a bottom value (e.g. by throwing some `ArithException`)https://gitlab.haskell.org/ghc/ghc/-/issues/11312GHC inlining primitive string literals can affect program output2019-07-07T18:30:58ZRyan ScottGHC inlining primitive string literals can affect program outputFirst noted in #11292, this program, when compiled with `-O1` or higher:
```hs
{-# LANGUAGE MagicHash #-}
module Main (main) where
import GHC.Exts (Addr#, isTrue#)
import GHC.Prim (eqAddr#)
data A = A { runA :: Addr# }
a :: A
a = A "...First noted in #11292, this program, when compiled with `-O1` or higher:
```hs
{-# LANGUAGE MagicHash #-}
module Main (main) where
import GHC.Exts (Addr#, isTrue#)
import GHC.Prim (eqAddr#)
data A = A { runA :: Addr# }
a :: A
a = A "a"#
main :: IO ()
main = print (isTrue# (eqAddr# (runA a) (runA a)))
```
will result in the following after inlining:
```
Main.main2 =
case GHC.Prim.tagToEnum#
@ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#)
of _ [Occ=Dead] {
GHC.Types.False -> GHC.Show.shows26;
GHC.Types.True -> GHC.Show.shows24
}
```
As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`.
Two questions:
1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them?
1. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #11292 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC inlining primitive string literals can affect program output","status":"New","operating_system":"","component":"Compiler","related":[11292],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First noted in #11292, this program, when compiled with `-O1` or higher:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MagicHash #-}\r\nmodule Main (main) where\r\n\r\nimport GHC.Exts (Addr#, isTrue#)\r\nimport GHC.Prim (eqAddr#)\r\n\r\ndata A = A { runA :: Addr# }\r\n\r\na :: A\r\na = A \"a\"#\r\n\r\nmain :: IO ()\r\nmain = print (isTrue# (eqAddr# (runA a) (runA a)))\r\n}}}\r\n\r\nwill result in the following after inlining:\r\n\r\n{{{\r\nMain.main2 =\r\n case GHC.Prim.tagToEnum#\r\n @ GHC.Types.Bool (GHC.Prim.eqAddr# \"a\"# \"a\"#)\r\n of _ [Occ=Dead] {\r\n GHC.Types.False -> GHC.Show.shows26;\r\n GHC.Types.True -> GHC.Show.shows24\r\n }\r\n}}}\r\n\r\nAs a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `\"a\"#` is not inlined, and as a result, `eqAddr#` returns `True`.\r\n\r\nTwo questions:\r\n\r\n1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them?\r\n2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `\"a\"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size.","type_of_failure":"OtherFailure","blocking":[]} -->