GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-09-29T15:25:07Zhttps://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/16197Strictness is not preserved under -O12021-09-21T14:11:59ZAlex LangStrictness is not preserved under -O1With -O0, the attached code prints:
```
> /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O0 src/foo.hs; and ./src/foo
[1 of 1] Compiling Main ( src/foo.hs, src/foo.o ) [Optimisation flags changed]
Linking src/foo ...
("exec",0)
("depth...With -O0, the attached code prints:
```
> /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O0 src/foo.hs; and ./src/foo
[1 of 1] Compiling Main ( src/foo.hs, src/foo.o ) [Optimisation flags changed]
Linking src/foo ...
("exec",0)
("depth",0)
("exec",1)
("depth",0)
```
But with -O1, it prints:
```
> /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O1 src/foo.hs; and ./src/foo
[1 of 1] Compiling Main ( src/foo.hs, src/foo.o )
Linking src/foo ...
("depth",0)
("depth",0)
```
Reproduced with 8.4.1 and 8.6.2. Doesn't seem to happen under 8.2.0
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | me@alang.ca |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Strictness is not preserved under -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["me@alang.ca"],"type":"Bug","description":"With -O0, the attached code prints:\r\n\r\n{{{\r\n> /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O0 src/foo.hs; and ./src/foo\r\n[1 of 1] Compiling Main ( src/foo.hs, src/foo.o ) [Optimisation flags changed]\r\nLinking src/foo ...\r\n(\"exec\",0)\r\n(\"depth\",0)\r\n(\"exec\",1)\r\n(\"depth\",0)\r\n}}}\r\n\r\nBut with -O1, it prints:\r\n\r\n{{{\r\n> /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O1 src/foo.hs; and ./src/foo\r\n[1 of 1] Compiling Main ( src/foo.hs, src/foo.o )\r\nLinking src/foo ...\r\n(\"depth\",0)\r\n(\"depth\",0)\r\n}}}\r\n\r\nReproduced with 8.4.1 and 8.6.2. Doesn't seem to happen under 8.2.0\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16111Inconsistent behavior of Data.Bits.shiftL with different optimization levels ...2020-08-29T12:43:54ZRyan ScottInconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvmConsider this program:
```hs
module Main (main) where
import Data.Bits
import Data.Word
main :: IO ()
main = print $ toInteger (shiftL 1 hm :: Word64)
== toInteger (shiftL 1 hm :: Word64)
hm :: Int
hm = -1
{-# NOINLINE hm...Consider this program:
```hs
module Main (main) where
import Data.Bits
import Data.Word
main :: IO ()
main = print $ toInteger (shiftL 1 hm :: Word64)
== toInteger (shiftL 1 hm :: Word64)
hm :: Int
hm = -1
{-# NOINLINE hm #-}
```
The result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used:
```
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
True
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
True
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
Bug: Bad shift length-1
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
True
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
False
$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
Bug: Bad shift length-1
```
This program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this program:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nimport Data.Bits\r\nimport Data.Word\r\n\r\nmain :: IO ()\r\nmain = print $ toInteger (shiftL 1 hm :: Word64)\r\n == toInteger (shiftL 1 hm :: Word64)\r\n\r\nhm :: Int\r\nhm = -1\r\n{-# NOINLINE hm #-}\r\n}}}\r\n\r\nThe result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used:\r\n\r\n{{{\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nTrue\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nTrue\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nBug: Bad shift length-1\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nTrue\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nFalse\r\n\r\n$ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug\r\n[1 of 1] Compiling Main ( Bug.hs, Bug.o )\r\nLinking Bug ...\r\nBug: Bad shift length-1\r\n}}}\r\n\r\nThis program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used!","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/16089seq is not cooperating with :sprint in GHCi as expected2023-08-29T00:32:45Zradrowseq is not cooperating with :sprint in GHCi as expectedI was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this mome...I was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost?
I am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._).
I have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation](https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation) to let others know.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"seq is not cooperating with :sprint in GHCi as expected","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["seq","sprint","strictness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was playing around with strictness and performed following test:\r\n\r\n{{{#!hs\r\nPrelude> x = [True, False]\r\nPrelude> :sprint x\r\nx = _\r\nPrelude> x `seq` True\r\nTrue\r\nPrelude> :sprint x\r\nx = _\r\n}}}\r\n\r\nI completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost? \r\n\r\nI am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._). \r\n\r\nI have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation] to let others know.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16031Show instance for Data.Fixed does not show parentheses for negatives2019-07-07T18:01:57ZSteven KeuchelShow instance for Data.Fixed does not show parentheses for negativesWhen showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic:
```hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Prelude> show (Just (-1 :: Int))
"Just (-1)"
P...When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic:
```hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Prelude> show (Just (-1 :: Int))
"Just (-1)"
Prelude> show (Just (-1 :: Float))
"Just (-1.0)"
```
However, the Show instance for Fixed does not
```hs
Prelude> :m Data.Fixed
Prelude Data.Fixed> show (Just (-1 :: Fixed E2))
"Just -1.00"
Prelude Data.Fixed>
```
I would expect it to, because of consistency and because the result "Just -1.00" is ill-typed when seen as an expression.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show instance for Data.Fixed does not show parentheses for negatives","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["Data.Fixed,","Show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic: \r\n\r\n{{{#!hs\r\nGHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help\r\nPrelude> show (Just (-1 :: Int))\r\n\"Just (-1)\"\r\nPrelude> show (Just (-1 :: Float))\r\n\"Just (-1.0)\"\r\n}}}\r\n\r\nHowever, the Show instance for Fixed does not\r\n\r\n{{{#!hs\r\nPrelude> :m Data.Fixed\r\nPrelude Data.Fixed> show (Just (-1 :: Fixed E2))\r\n\"Just -1.00\"\r\nPrelude Data.Fixed> \r\n}}}\r\n\r\nI would expect it to, because of consistency and because the result \"Just -1.00\" is ill-typed when seen as an expression.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Sven TennieSven Tenniehttps://gitlab.haskell.org/ghc/ghc/-/issues/15856GhostScript not available for hp2ps tests2019-07-07T18:02:42Zjrp2014GhostScript not available for hp2ps testsWhen I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer...When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).
The message "GhostScript not available for hp2ps tests" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.
There are probably 2 ways forward:
- a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable
- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GhostScript not available for hp2ps tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["ghostscript","gs","hp2ps","testsuite"],"differentials":[],"test_case":"","architecture":"","cc":["Simonmar"],"type":"Bug","description":"When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.\r\n\r\nI don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).\r\n\r\nThe message \"GhostScript not available for hp2ps tests\" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.\r\n\r\nThere are probably 2 ways forward:\r\n\r\n - a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable\r\n\r\n- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/15460Literals overflow2019-07-07T18:04:41ZSylvain HenryLiterals overflowConsider the following example:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
print x
```
It gets desugared into:
```hs
m...Consider the following example:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
print x
```
It gets desugared into:
```hs
main
= print
@ Int
GHC.Show.$fShowInt
(GHC.Types.I#
7237005577332262213973186563042994240829374041602535252466099000494570602495#)
```
Problem: the literal value isn't rounded and there is no overflow warning.
It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant:
```hs
{-# LANGUAGE MagicHash #-}
import GHC.Int
main :: IO ()
main = do
let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#)
if (x > maxBound)
then print "Oups"
else print "Ok"
> ghc TestLitOverflow.hs -Wall -O0
> ./TestLitOverflow
"Ok"
> ghc TestLitOverflow.hs -Wall -O2
> ./TestLitOverflow
"Oups"
```8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/13513Incorrect behavior on arm64 with optimisations2019-08-10T10:52:20ZArtem ChirkinIncorrect behavior on arm64 with optimisationsI compiled ghc manually on a chromebook running ubuntu on aarch64 (arm64). I used `perf-llvm` build during compilation. This might be related to [https://ghc.haskell.org/trac/ghc/ticket/11578](https://ghc.haskell.org/trac/ghc/ticket/1157...I compiled ghc manually on a chromebook running ubuntu on aarch64 (arm64). I used `perf-llvm` build during compilation. This might be related to [https://ghc.haskell.org/trac/ghc/ticket/11578](https://ghc.haskell.org/trac/ghc/ticket/11578), but I am not sure how.
While working with stack and cabal I experienced unusually long compilation times or seemingly random build failures from time to time. Luckily, at some point I got very interesting error in package `text`:
```hs
Prelude> import qualified Data.Text as T
Prelude T> T.splitOn (T.pack " ") (T.pack "Hello world!")
["Hello","world!\54497\44724?\NUL\54521\44724?\NUL\NUL\NUL\NUL\NUL\34560...BIG BLOB OF BYTES HERE...\NUL"]
```
By default this package compiles with `-O2`, so I tried various options to determine when the result is correct and when is not.
To test this I used bare GHC installation and `cabal-install-1.24.0.2`, (`cabal sandbox init && cabal install text --ghc-options="..."`).
Here is what I tried so far:
- BAD: `-O2`
- BAD: `-O2 -fllvm -optlc-O3`
- OK: `-O1 -fllvm -optlc-O3`
- OK: `-O1 -fllvm -fliberate-case -fregs-graph -fspec-constr -optlc-O3`
That is: when `text` package is compiled with `-O2` the result of `Text.splitOn` function is garbaged with random data; when it is compiled with `-O1`, the result is correct.
Since `text` is represented using `ByteArray#` internally, I would suggest something is wrong with `ByteArray#`'s length attribute, but I am not sure.
<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":"Incorrect behavior on arm64 with optimisations","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 compiled ghc manually on a chromebook running ubuntu on aarch64 (arm64). I used `perf-llvm` build during compilation. This might be related to [https://ghc.haskell.org/trac/ghc/ticket/11578], but I am not sure how.\r\n\r\nWhile working with stack and cabal I experienced unusually long compilation times or seemingly random build failures from time to time. Luckily, at some point I got very interesting error in package `text`:\r\n{{{#!hs\r\nPrelude> import qualified Data.Text as T\r\nPrelude T> T.splitOn (T.pack \" \") (T.pack \"Hello world!\")\r\n[\"Hello\",\"world!\\54497\\44724?\\NUL\\54521\\44724?\\NUL\\NUL\\NUL\\NUL\\NUL\\34560...BIG BLOB OF BYTES HERE...\\NUL\"]\r\n}}}\r\nBy default this package compiles with `-O2`, so I tried various options to determine when the result is correct and when is not.\r\nTo test this I used bare GHC installation and `cabal-install-1.24.0.2`, (`cabal sandbox init && cabal install text --ghc-options=\"...\"`).\r\n\r\nHere is what I tried so far:\r\n\r\n * BAD: `-O2`\r\n * BAD: `-O2 -fllvm -optlc-O3`\r\n * OK: `-O1 -fllvm -optlc-O3`\r\n * OK: `-O1 -fllvm -fliberate-case -fregs-graph -fspec-constr -optlc-O3`\r\n\r\nThat is: when `text` package is compiled with `-O2` the result of `Text.splitOn` function is garbaged with random data; when it is compiled with `-O1`, the result is correct.\r\nSince `text` is represented using `ByteArray#` internally, I would suggest something is wrong with `ByteArray#`'s length attribute, but I am not sure.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1