GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-11-13T21:59:02Zhttps://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/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...2019-12-06T20:12:40ZtaylorfausakRounding 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/17151Optimizer produces Core with an infinite <<loop>> v22021-04-07T15:53:50ZAlexey 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/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_64KevinBuhrKevinBuhr