GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-09-12T00:31:00Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/18370`BlockedIndefinitelyOnMVar` is thrown to non-blocked threads2022-09-12T00:31:00ZOle`BlockedIndefinitelyOnMVar` is thrown to non-blocked threads## Summary
`BlockedIndefinitelyOnMVar` is thrown to other threads that weren't blocked.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control...## Summary
`BlockedIndefinitelyOnMVar` is thrown to other threads that weren't blocked.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control.Exception
main :: IO ()
main = do
emptyVar <- newEmptyMVar @()
resultVar <- newEmptyMVar
_ <- forkIO $ do
caught <- try @SomeException (readMVar emptyVar)
putMVar resultVar caught
print ("thread", caught)
result <- readMVar resultVar
print ("main", result)
```
```
$ ghc -Wall -Wextra -threaded Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
("thread",Left thread blocked indefinitely in an MVar operation)
Test: thread blocked indefinitely in an MVar operation
$ ./Test +RTS -N
Test: thread blocked indefinitely in an MVar operation
("thread",Left thread blocked indefinitely in an MVar operation)
```
It appears the main thread is being thrown a `BlockedIndefinitelyOnMVar` as well.
This can be decoupled from the empty MVar read:
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control.Concurrent.STM
import Control.Exception
main :: IO ()
main = do
emptyVar <- newEmptyTMVarIO @()
resultVar <- newEmptyMVar
_ <- forkIO $ do
caught <- try @SomeException (atomically (readTMVar emptyVar))
putMVar resultVar caught
print ("thread", caught)
result <- readMVar resultVar
print ("main", result)
```
```
$ ghc -Wall -Wextra -threaded Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
("thread",Left thread blocked indefinitely in an STM transaction)
Test: thread blocked indefinitely in an MVar operation
$ ./Test +RTS -N
Test: thread blocked indefinitely in an MVar operation
("thread",Left thread blocked indefinitely in an STM transaction)
```
## Expected behavior
I expect both threads to print the result of `try` in unspecified order.
```
λ ./Test +RTS -N
("thread",Left thread blocked indefinitely in an MVar operation)
("main",Left thread blocked indefinitely in an MVar operation)
```
## Environment
* GHC version used:
- 8.10.1
- 8.8.3
Optional:
* Operating System: NixOS, Linux 5.4.31 x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/18269Closure size functions will return incorrect for closures with static links2020-06-02T14:12:21ZÖmer Sinan AğacanClosure size functions will return incorrect for closures with static linksNot sure if this is a bug or not, but here goes.
Closure size functions like `closureSize#` (primop) and `closure_size` (C function) don't take static link fields into account, so they will return incorrect result for top-level construc...Not sure if this is a bug or not, but here goes.
Closure size functions like `closureSize#` (primop) and `closure_size` (C function) don't take static link fields into account, so they will return incorrect result for top-level constructors (e.g. SRTs, or CAFFY constructors).
It seems like the assumption here is they'll always be passed heap-allocated closures, but as far as I can see this fact is not documented, e.g. in `ghc-heap`'s `closureSize`:
```haskell
-- | Get the size of the top-level closure in words.
-- Includes header and payload. Does not follow pointers.
--
-- @since 8.10.1
closureSize :: Box -> Int
closureSize (Box x) = I# (closureSize# x)
```
Note that, confusingly, "top-level" here means that the function does not recursively visit payloads, not that the closure is actually top-level!https://gitlab.haskell.org/ghc/ghc/-/issues/18151Eta-expansion of a left-section2021-01-12T23:04:49ZRichard Eisenbergrae@richarde.devEta-expansion of a left-sectionIf I say
```hs
x = seq (True `undefined`) ()
```
what should I get when evaluating `x`?
According to my understanding of the Haskell Report, I should get `()`. And according to my understanding of GHC's source code (in `GHC.Tc.Gen.Exp...If I say
```hs
x = seq (True `undefined`) ()
```
what should I get when evaluating `x`?
According to my understanding of the Haskell Report, I should get `()`. And according to my understanding of GHC's source code (in `GHC.Tc.Gen.Expr`), I should get `()`. But I get an exception.
Why?
NB: `-XPostfixOperators` is off. If it were on, the exception would be expected.
Spun off from https://github.com/ghc-proposals/ghc-proposals/pull/275#issuecomment-6242820229.0.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/18101DeriveGeneric gets a wrong infix constructor associativity when type is decla...2023-04-09T15:41:35ZXia Li-yaoDeriveGeneric gets a wrong infix constructor associativity when type is declared in a different module## Summary
For example, the operators `(:|)` (`NonEmpty`) and `(:)` (lists, `[]`) are `infixr 5`, but their `Generic.Rep` say otherwise (`'InfixI 'LeftAssociative 9`) (see code block below for an illustration).
My most plausible hypoth...## Summary
For example, the operators `(:|)` (`NonEmpty`) and `(:)` (lists, `[]`) are `infixr 5`, but their `Generic.Rep` say otherwise (`'InfixI 'LeftAssociative 9`) (see code block below for an illustration).
My most plausible hypothesis for the cause is that `DeriveGeneric` does not take precedence into account when the type lives in a different module from its `Generic` instance. Indeed, `NonEmpty` and `[]` have their `Generic` instances derived in `GHC.Generic`, whereas things looks fine if we declare a type with an infix constructor and derive `Generic` in the same module.
```
ghci> :kind! (Rep [Int])
(Rep [Int]) :: * -> *
= D1
('MetaData "[]" "GHC.Types" "ghc-prim" 'False)
(C1 ('MetaCons "[]" 'PrefixI 'False) U1
:+: C1
('MetaCons ":" ('InfixI 'LeftAssociative 9) 'False)
...)
ghci> :kind! (Rep (NonEmpty Int))
(Rep (NonEmpty Int)) :: * -> *
= D1
('MetaData "NonEmpty" "GHC.Base" "base" 'False)
(C1
('MetaCons ":|" ('InfixI 'LeftAssociative 9) 'False)
...)
```
## Expected behavior
These two examples should read `'InfixI 'RightAssociative 5`.
## Environment
* GHC version used: 8.6, 8.89.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/17970Global variables in GHC.IO.Encoding have inappropriate inlinings2020-03-31T14:58:34ZBen GamariGlobal variables in GHC.IO.Encoding have inappropriate inliningsWhile looking into #17947 I noticed that `GHC.IO.Encoding.getFileSystemEncoding` and friends, which are supposed to be global variables, exposes an unfolding:
```haskell
$ _build/stage1/bin/ghc --show-iface _build/stage1/libraries/base/b...While looking into #17947 I noticed that `GHC.IO.Encoding.getFileSystemEncoding` and friends, which are supposed to be global variables, exposes an unfolding:
```haskell
$ _build/stage1/bin/ghc --show-iface _build/stage1/libraries/base/build/GHC/IO/Encoding.hi
...
c5f268cd1abea1e17607b29083a07ddf
getFileSystemEncoding ::
GHC.Types.IO GHC.IO.Encoding.Types.TextEncoding
[Unfolding: (case getFileSystemEncoding1 of wild { (,) getFileSystemEncoding81 setFileSystemEncoding1 ->
getFileSystemEncoding81 })]
877b4ce4c0c06df59a38c01a0a2f65ea
getFileSystemEncoding1 ::
(GHC.Types.IO GHC.IO.Encoding.Types.TextEncoding,
GHC.IO.Encoding.Types.TextEncoding -> GHC.Types.IO ())
[Unfolding: (case GHC.Magic.runRW#
@('GHC.Types.TupleRep
'[ 'GHC.Types.TupleRep '[], 'GHC.Types.LiftedRep])
@(# GHC.Prim.State# GHC.Prim.RealWorld,
(GHC.Types.IO GHC.IO.Encoding.Types.TextEncoding,
GHC.IO.Encoding.Types.TextEncoding -> GHC.Types.IO ()) #)
getFileSystemEncoding2 of ds { (#,#) ipv ipv1 ->
ipv1 })]
...
01c6dd64e835d1d407d95b7dea54fa17
getFileSystemEncoding2 ::
GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
(GHC.Types.IO GHC.IO.Encoding.Types.TextEncoding,
GHC.IO.Encoding.Types.TextEncoding -> GHC.Types.IO ()) #)
[Arity: 1, Strictness: <L,U>,
Unfolding: (\ (s :: GHC.Prim.State# GHC.Prim.RealWorld)[OneShot] ->
case GHC.Prim.noDuplicate# @GHC.Prim.RealWorld s of s' { DEFAULT ->
case GHC.Prim.newMutVar#
@GHC.IO.Encoding.Types.TextEncoding
@GHC.Prim.RealWorld
getFileSystemEncoding3
s' of ds { (#,#) ipv ipv1 ->
(# ipv,
((\ (eta :: GHC.Prim.State# GHC.Prim.RealWorld) ->
GHC.Prim.readMutVar#
@GHC.Prim.RealWorld
@GHC.IO.Encoding.Types.TextEncoding
ipv1
eta)
`cast`
(Sym (GHC.Types.N:IO[0] <GHC.IO.Encoding.Types.TextEncoding>_R)),
(\ (v :: GHC.IO.Encoding.Types.TextEncoding)
(eta :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case GHC.Prim.writeMutVar#
@GHC.Prim.RealWorld
@GHC.IO.Encoding.Types.TextEncoding
ipv1
v
eta of s2# { DEFAULT ->
(# s2#, GHC.Tuple.() #) })
`cast`
(<GHC.IO.Encoding.Types.TextEncoding>_R
->_R Sym (GHC.Types.N:IO[0] <()>_R))) #) } })]
```
This will break the "globalness" of these variables, potentially breaking `setFileSystemEncoding` and others.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17950OFD locking breaks on 32-bit glibc2021-05-04T23:17:40ZBen GamariOFD locking breaks on 32-bit glibcAs noted in #17941, some [glibc versions](https://sourceware.org/bugzilla/show_bug.cgi?id=20251) use the wrong `struct` layout for the open fd locking `fcntl` on 32-bit platforms. This results in GHC being broken on many 32-bit platforms...As noted in #17941, some [glibc versions](https://sourceware.org/bugzilla/show_bug.cgi?id=20251) use the wrong `struct` layout for the open fd locking `fcntl` on 32-bit platforms. This results in GHC being broken on many 32-bit platforms by default.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17694ParallelListComp semantics differs from the documented one2021-12-21T23:01:00ZRoman CheplyakaParallelListComp semantics differs from the documented oneThe desugaring of parallel list comprehensions described [in the manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#parallel-list-comprehensions) appears to state that parallel bars (`|`) have highe...The desugaring of parallel list comprehensions described [in the manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#parallel-list-comprehensions) appears to state that parallel bars (`|`) have higher precedence than what comes after them, but this is not how they work in practice.
## Example 1
``` haskell
{-# LANGUAGE ParallelListComp #-}
main = print
[ (a, b)
| a <- [1 .. 5]
| b <- [1 .. 5]
, b >= 4
]
```
The desugaring implied by the docs is
``` haskell
main = print
[ (a, b)
| (a, b) <- zip [1 .. 5] [1 .. 5]
, b >= 4
]
```
so I'd expect the result to be [(4,4),(5,5)]. Yet the actual result is [(1,4),(2,5)], showing that the comma has higher precedence here.
## Example 2
``` haskell
{-# LANGUAGE ParallelListComp #-}
main = print
[ (a, b)
| a <- [1 .. 5]
| b <- [1 .. 5]
, a >= 4
]
```
Result:
```
parlistcomp.hs:7:5: error:
• Variable not in scope: a :: Integer
• Perhaps you meant ‘a’ (line 5)
|
7 | , a >= 4
| ^
```
Again, this is consistent with the comma binding more tightly than the bar. But also notice that ghc itself is confused about the scoping rules: it says `a` is not in scope, yet suggests `a` as a valid replacement.
## Environment
* GHC version used: 8.6.5, 8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/17678text has different runtime behavior between GHC 8.6.5 and 8.8.12020-01-13T18:40:51ZRyan Scotttext has different runtime behavior between GHC 8.6.5 and 8.8.1If you compile the following file:
```hs
module Main (main) where
import qualified Data.Char as C
import Data.Char (isLetter, isLower)
import Data.Maybe (mapMaybe)
import qualified Data.Text as T
import Da...If you compile the following file:
```hs
module Main (main) where
import qualified Data.Char as C
import Data.Char (isLetter, isLower)
import Data.Maybe (mapMaybe)
import qualified Data.Text as T
import Data.Text (Text)
main :: IO ()
main = print $ t_toTitle_1stNotLower
$ T.pack "\4309" -- ვ
-- Taken from the text test suite
-- https://github.com/haskell/text/blob/44ec2cee65e5326ed943370e424f60d4ae6206d1/tests/Tests/Properties.hs#L388-L396
t_toTitle_1stNotLower :: Text -> Bool
t_toTitle_1stNotLower = and . notLow . T.toTitle . T.filter stable
where notLow = mapMaybe (fmap (not . isLower) . (T.find isLetter)) . T.words
-- Surprise! The Spanish/Portuguese ordinal indicators changed
-- from category Ll (letter, lowercase) to Lo (letter, other)
-- in Unicode 7.0
-- Oh, and there exist lowercase-only letters (see previous test)
stable c = if isLower c
then C.toUpper c /= c
else c /= '\170' && c /= '\186'
```
Then you'll get different runtime results depending on which version of GHC you use. Here is the answer with GHC 8.6.5:
```
$ /opt/ghc/8.6.5/bin/ghc Bug.hs -fforce-recomp -v0 && ./Bug
True
```
And here is the answer with GHC 8.8.1, 8.10.1-alpha2, and HEAD:
```
$ /opt/ghc/8.8.1/bin/ghc Bug.hs -fforce-recomp -v0 && ./Bug
False
```
This discrepancy manifests itself regardless of what GHC optimization level is used.https://gitlab.haskell.org/ghc/ghc/-/issues/17458Runtime loop when using eqT2019-11-13T21:59:02ZMax HarmsRuntime loop when using eqT## Summary
Use of eqT causes run-time divergence in a weird edge-case.
## Steps to reproduce
This example is minimized for simplicity; my actual use case was large and it took me 5 hours to get it down to this:
```haskell
{-# LANGUAGE...## Summary
Use of eqT causes run-time divergence in a weird edge-case.
## Steps to reproduce
This example is minimized for simplicity; my actual use case was large and it took me 5 hours to get it down to this:
```haskell
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE TypeOperators #-}
import Data.Void
import Data.Typeable
import Data.Type.Equality
class (forall k. k a => k b) => Equ a b
instance Equ a a
data Z' a where
Z' :: Z' Void
data Z where
Z :: forall a. Equ Void a => Z' a -> Z
checkZ :: Z -> Bool
checkZ (Z (Z' :: Z' a)) = case eqT of
Nothing -> False
Just (Refl :: a :~: Void) -> True
main :: IO ()
main = do
putStrLn "before..."
print $ checkZ $ Z Z'
putStrLn "after!"
```
Compiles ok. Exe output is:
```
before...
MinExample: <<loop>>
```
## Expected behavior
This should work and produce
```
before...
True
after...
```
Poking around indicates that Eq can propagate along the quantified constraint of `Equ`, but apparently something magic is happening with Typeable?
## Environment
Tested with GHC 8.6 and 8.8 on NixOS.https://gitlab.haskell.org/ghc/ghc/-/issues/17451surprising SIGQUIT behavior "This build does not support backtraces."2019-11-08T21:51:17Zjoeyhsurprising SIGQUIT behavior "This build does not support backtraces."## Summary
I hit ctrl-\ to send a hard SIGQUIT to my program, which I knew does not install a handler for that and wanted to exit immediately (w/o running its usual SIGINT handler), and was surprised to see "This build does not support ...## Summary
I hit ctrl-\ to send a hard SIGQUIT to my program, which I knew does not install a handler for that and wanted to exit immediately (w/o running its usual SIGINT handler), and was surprised to see "This build does not support backtraces." and the program contining to run.
I happened to have run my program from a shell script, and the SIGQUIT terminated the shell that had run it, which left my program running in a kind of backgrounded state where it contended with my interactive shell. And my program happened to have run another program and was itself surprised to see that program, which also received the SIGQUIT, exiting unexpectedly with an unusual exit code.
I think there's a reasonable expectation that SIGQUIT leads to a prompt terminatation of the program, with or without a core dump or something associated with a core dump such as a backtrace. Leaving the program running and printing out an unusual (and untranslated BTW) message to stderr has a high potential to exercise unusual code paths. Some programs may have a good reason to not exit on SIGQUIT, but then the program has to be designed to work that way. ghc is assuming any program will work acceptably if it keeps running after a SIGQUIT, and that is not the case.
In Signals.c, I'd suggest only installing the SIGQUIT handler #if USE_LIBDW.
Or, if it's important to communicate the the user that it was not built with backtrace support, it could display the message and then exit.
(It looks like the program might keep running when built with LIBDW too, and maybe that's intentional in order to see repeated backtraces, but I think my reasoning on prompt termination could also apply there.)
## Steps to reproduce
Start a long-running git-annex operation, like a "git annex add" in a directory with ots of files, and send it a SIGQUIT.
## Expected behavior
Terminate immediately.
## Environment
* GHC version used: 8.6.5 from Debian
Optional:
* Operating System: Linux
* System Architecture: 864-64https://gitlab.haskell.org/ghc/ghc/-/issues/17383Data.Fixed.mod' sometimes produces nonsensical results2019-10-31T23:03:13ZRoman CheplyakaData.Fixed.mod' sometimes produces nonsensical results## Summary
```
Prelude Data.Fixed> (-3e19) `mod'` 1.4
-4096.0
Prelude Data.Fixed> 4.9098418106168856e20 `mod'` (-43.4678352235136)
65536.0
Prelude Data.Fixed> (-10) `mod'` exp (-43)
-1.7763568394002505e-15
```
## Expected behavior
My ...## Summary
```
Prelude Data.Fixed> (-3e19) `mod'` 1.4
-4096.0
Prelude Data.Fixed> 4.9098418106168856e20 `mod'` (-43.4678352235136)
65536.0
Prelude Data.Fixed> (-10) `mod'` exp (-43)
-1.7763568394002505e-15
```
## Expected behavior
My understanding is that `mod'` should yield a result whose absolute value is smaller than the absolute value of the divisor and which is positive when the divisor is positive.
The fact that some of the above results happen to be powers of 2 is also curious.
## Environment
* GHC version used:
8.6.58.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17303Rounding always throws an arithmetic underflow exception when used with a rat...2022-02-03T01:23:43ZtaylorfausakRounding always throws an arithmetic underflow exception when used with a ratio of natural numbersI originally reported this in !1878.
Today I was surprised to find that `round` does not work at all for `Ratio Natural` values. For example:
``` hs
>>> round (1 :: Ratio Natural) :: Natural
*** Exception: arithmetic underflow
```
As...I originally reported this in !1878.
Today I was surprised to find that `round` does not work at all for `Ratio Natural` values. For example:
``` hs
>>> round (1 :: Ratio Natural) :: Natural
*** Exception: arithmetic underflow
```
As far as I can tell it's true regardless of the value of the `Ratio Natural` or the result type.
``` hs
>>> round (1.5 :: Ratio Natural) :: Natural
*** Exception: arithmetic underflow
>>> round (1 :: Ratio Natural) :: Integer
*** Exception: arithmetic underflow
```
For comparison, rounding works fine for `Rational`, which is an alias for `Ratio Integer`.
``` hs
>>> round (1 :: Rational) :: Integer
1
>>> round (1.5 :: Rational) :: Integer
2
>>> round (1 :: Rational) :: Natural
1
```8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17285Program hangs on ppc64el2019-11-03T11:10:47ZIlias TsitsimpisProgram hangs on ppc64el## Summary
The testsuite for terminal-progress-bar fails (hangs) on both ppc64el and ppc64 (see build logs [here](https://buildd.debian.org/status/package.php?p=haskell-terminal-progress-bar&suite=sid)).
## Steps to reproduce
In order...## Summary
The testsuite for terminal-progress-bar fails (hangs) on both ppc64el and ppc64 (see build logs [here](https://buildd.debian.org/status/package.php?p=haskell-terminal-progress-bar&suite=sid)).
## Steps to reproduce
In order to reproduce this, I tried the following on ppc64el:
```bash
$ cabal install terminal-progress-bar==0.4.1
$ cat Progress.hs
module Main where
import Data.Time.Clock
import System.ProgressBar
main = do
print $ renderProgressBar defStyle (Progress 0 1 ()) someTiming
where
someTime :: UTCTime
someTime = UTCTime (toEnum 0) 0
someTiming :: Timing
someTiming = Timing someTime someTime
$ ghc -o progress Progress.hs
$ ./progress
```
This hangs forever, with the process taking 100% CPU.
The interesting part is that if I modify the [ProgressBar.hs](https://github.com/roelvandijk/terminal-progress-bar/blob/master/lib/src/System/ProgressBar.hs) file to contain the above main function, and compile that one, it finishes successfully. This is why I assume this is a GHC bug.
## Environment
* GHC version used: 8.6.5
I tried the same think with v8.4.4 from Debian buster and it run without a problem, so this is a regression.https://gitlab.haskell.org/ghc/ghc/-/issues/17206Unsound optimization with -O in ghc 8.4 and 8.6 when using unsafeCoerce (prod...2019-09-19T13:06:42ZAndreas AbelUnsound optimization with -O in ghc 8.4 and 8.6 when using unsafeCoerce (produced by Agda)## Summary
Unsound optimization of `unsafeCoerce` with `-O` under GHC 8.4 and 8.6.
The following code was shrunk from code generated by the GHC backend of Agda. Agda in essence targets the untyped lambda calculus, thus, uses `unsafeCo...## Summary
Unsound optimization of `unsafeCoerce` with `-O` under GHC 8.4 and 8.6.
The following code was shrunk from code generated by the GHC backend of Agda. Agda in essence targets the untyped lambda calculus, thus, uses `unsafeCoerce` excessively. This was unproblematic until GHC 8.2 and seems to be fine again from GHC 8.8.
## Steps to reproduce
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module Main where
import Prelude (IO, ($), (.), (>>=), putStrLn)
import System.Exit (exitFailure)
import Unsafe.Coerce (unsafeCoerce)
sequ :: IO () -> IO a -> IO a
sequ c c' = c >>= \ _ -> c'
main :: IO ()
main =
unsafeCoerce sequ (putStrLn "Hello,") $
unsafeCoerce sequ (putStrLn "world!") $
exitFailure
```
With 8.4.x or 8.6.x run
```
ghc -O Main.hs
./Main
```
The output is
```
Hello,
```
and exitcode is 0.
## Expected behavior
Output [UPDATE: this output is produced when compiling with 8.8, 8.2, 8.0]
```
Hello,
world!
```
and exitcode 1.
## Environment
* GHC version used: 8.4.4 and 8.6.4
Optional:
* Operating System: Mac Mojavehttps://gitlab.haskell.org/ghc/ghc/-/issues/17151Optimizer produces Core with an infinite <<loop>> v22022-08-06T23:27:36ZAlexey KuleshevichOptimizer produces Core with an infinite <<loop>> v2## Summary
I am not quite sure what it is? Is it coincidence, my coding style or just luck. Two years later after I reported a bug #13429 about optimizer generating an infinite loop, I stumble upon exactly the same bug, while implementi...## Summary
I am not quite sure what it is? Is it coincidence, my coding style or just luck. Two years later after I reported a bug #13429 about optimizer generating an infinite loop, I stumble upon exactly the same bug, while implementing the same algorithm (convolution), but in a completely different library and using a totally different approach. There are some similarities in types, but I can't draw a concrete comparison.
Unlike previous bug #13429, which was applicable to ghc-8.0 and was supposably fixed in ghc-8.2, this one is triggered in ghc-8.2 and up, but not for the prior version.
It is way too easy not not trigger the bug, in fact I initially noticed my tests failing for ghc-8.4.4 only, but once I reduced it to a smaller example, my tests started failing for ghc-8.6.5 as well as ghc-8.8.1
I apologize for the size of the uploaded module, but it took me a while to reduce it even to that level.
## Steps to reproduce
Uploaded are the two files needed to reproduce the bug:
* [Main.hs](/uploads/336cf55e11fb30f34178d2d0cd1d4ffe/Main.hs)
* [Array.hs](/uploads/0680b1bdd353b7632f6d3d96e6d95f8b/Array.hs)
Those modules only depend on `primitive` package, but this is only for convenience, since this bug could equally well be reproduced using either `ForeignPtr` or by dropping down to `ByteArray#` or `MutableByteArray#` prims.
Compiling with optimizations is necessary to trigger the bug:
```shell
$ ghc Main.hs Array.hs -O1 -fforce-recomp && ./Main
[1 of 2] Compiling Array ( Array.hs, Array.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
Main: <<loop>>
```
When inspecting Core we can see where the loop occurs right away:
```
Rec {
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
$s$fConstructPixe1 :: Index Int
$s$fConstructPixe1 = $s$fConstructPixe1
end Rec }
```
I found something peculiar, which could be useful for debugging this issue, is that the `Construct` instance for `P` representation is not used anywhere directly in the source code.
## Expected behavior
No infinite loop in the produced binary.
## Environment
* GHC version used: 8.2.2 - 8.8.1
Optional:
* Operating System: Ubuntu 18.04 LTS
* System Architecture: x86_648.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16810Use explicit lazy binding around undefined in inlinable functions2021-10-04T14:19:35Zkazu-yamamotoUse explicit lazy binding around undefined in inlinable functions# Summary
`undefined` in inlinable functions are unintentionally evaluated if called strictly. An example:
```
{-# INLINE alloca #-}
alloca :: forall a b . Storable a => (Ptr a -> IO b) -> IO b
alloca =
allocaBytesAligned (sizeOf (u...# Summary
`undefined` in inlinable functions are unintentionally evaluated if called strictly. An example:
```
{-# INLINE alloca #-}
alloca :: forall a b . Storable a => (Ptr a -> IO b) -> IO b
alloca =
allocaBytesAligned (sizeOf (undefined :: a)) (alignment (undefined :: a))
```
# Steps to reproduce
Use `Foreign.Marshal.Alloc.alloca` with `Strict` language extension.
# Expected behavior
It should allocate a memory, not evaluating `undefined`. If `undefined`s are used in inlinable functions, lazy bindings must be used explicitly for GHC 8.0 or later.
# Environment
* GHC version used: 8.0 or later
Optional:8.9https://gitlab.haskell.org/ghc/ghc/-/issues/16713-fno-omit-yields doesn't work at -O02019-06-05T16:36:03Zroland-fno-omit-yields doesn't work at -O0```haskell
import Control.Concurrent
import Control.Monad
main = do
forkIO $ forever $ return ()
threadDelay 100000
putStrLn "done!"
````
In #8521 compiling with `-fno-omit-yields` was suggested, in order to make the tight loop y...```haskell
import Control.Concurrent
import Control.Monad
main = do
forkIO $ forever $ return ()
threadDelay 100000
putStrLn "done!"
````
In #8521 compiling with `-fno-omit-yields` was suggested, in order to make the tight loop yield. This appears to work at `-O1`:
```
$ ghc -O1 -threaded -fno-omit-yields Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o ) [Optimisation flags changed]
Linking Bug ...
$ ./Bug +RTS -N2
done!
```
...but not at `-O0`:
```
$ ghc -O0 -threaded -fno-omit-yields Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o ) [Optimisation flags changed]
Linking Bug ...
$ ./Bug +RTS -N2
^C^C
```
Also, I don't understand why `-fno-omit-yields` is at all required when running with `-N2`. If the `forever $ return ()` thread hogs one capability without yielding, wouldn't there be a second one left for the main thread to run on?
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5
```https://gitlab.haskell.org/ghc/ghc/-/issues/16617On x86_64, `castFloatToWord32` can generate bad, signed `Word32`s2019-05-24T19:53:10ZKevinBuhrOn 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_64KevinBuhrKevinBuhrhttps://gitlab.haskell.org/ghc/ghc/-/issues/16586KnownNat: result changes depending on optimizations2022-09-29T15:25:07ZBodigrimKnownNat: result changes depending on optimizations# Summary
The following program changes output from `1` (without optimizations) to `331` (with `-O1`).
# Steps to reproduce
```haskell
{-# LANGUAGE DataKinds, PolyKinds, RankNTypes, ScopedTypeVariables #-}
module Main where
import D...# Summary
The following program changes output from `1` (without optimizations) to `331` (with `-O1`).
# Steps to reproduce
```haskell
{-# LANGUAGE DataKinds, PolyKinds, RankNTypes, ScopedTypeVariables #-}
module Main where
import Data.Proxy
import GHC.TypeNats
import Numeric.Natural
newtype Foo (m :: Nat) = Foo { getVal :: Word }
mul :: KnownNat m => Foo m -> Foo m -> Foo m
mul mx@(Foo x) (Foo y) =
Foo $ x * y `rem` fromIntegral (natVal mx)
pow :: KnownNat m => Foo m -> Int -> Foo m
pow x k = iterate (`mul` x) (Foo 1) !! k
modl :: (forall m. KnownNat m => Foo m) -> Natural -> Word
modl x m = case someNatVal m of
SomeNat (_ :: Proxy m) -> getVal (x :: Foo m)
main :: IO ()
main = print $ (Foo 127 `pow` 31336) `modl` 31337
dummyValue :: Word
dummyValue = (Foo 33 `pow` 44) `modl` 456
```
```
$ ghc -fforce-recomp Mod.hs && ./Mod
1
$ ghc -fforce-recomp -O Mod.hs && ./Mod
313
```
# Expected behavior
The [expected output](https://www.wolframalpha.com/input/?i=127+%5E+31336+mod+31337) is `1`.
While `dummyValue` is absolutely unused and should not have any impact, compilation with `-O` somehow replaces `31337` in `main` with `456`, producing [313](https://www.wolframalpha.com/input/?i=127+%5E+31336+mod+456). This can be also verified by dumping Core: it does not even contain `31337` anywhere, but surprisingly includes `456`.
Any of the following restores the behaviour of `-O1` program to expected:
* Remove `module Main where` line.
* Switch from `GHC.TypeNats` to `GHC.TypeLits`.
* Change ``(`mul` x)`` to `(mul x)`.
# Environment
* GHC version used: 8.6.4
* Operating System: macOS 10.14.4
* System Architecture: x648.8.1Iavor S. DiatchkiIavor S. Diatchkihttps://gitlab.haskell.org/ghc/ghc/-/issues/16514Fix for #14619 is wrong2020-02-25T01:14:44ZDuane RyragFix for #14619 is wrongThe fix for #14619 is wrong. Please see https://gitlab.haskell.org/ghc/ghc/commit/add4e1f11b88cd603f6c01bc135eb576e1922a8e#note_190830.The fix for #14619 is wrong. Please see https://gitlab.haskell.org/ghc/ghc/commit/add4e1f11b88cd603f6c01bc135eb576e1922a8e#note_190830.8.6.5