Incorrect behavior on arm64 with optimisations
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.
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:
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.
Trac metadata
| 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 |