GHC doesn't optimize FP excess precision properly
jmcarthur helped in constructing the test case. Consider the following program:
module Main where
{-# NOINLINE x #-}
{-# NOINLINE y #-}
x, y :: Double
x = 3
y = 7
main = print $ x/y == (3/7 :: Double)
When run on 32-bit Linux, we get the following results:
ezyang@javelin:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
ezyang@javelin:~$ ghc --make Bar.hs -o Bar -O0 -fforce-recomp && ./Bar
[1 of 1] Compiling Main ( Bar.hs, Bar.o )
Linking Bar ...
True
ezyang@javelin:~$ ghc --make Bar.hs -o Bar -O -fforce-recomp && ./Bar
[1 of 1] Compiling Main ( Bar.hs, Bar.o )
Linking Bar ...
False
The second result should be True (and only false if -fexcess-precision
is specified). I also tested on a devel2 build of GHC HEAD and got similar results.
This appears to be a regression from 6.12.1:
ezyang@javelin:~$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
ezyang@javelin:~$ /usr/bin/ghc --make Bar.hs -o Bar -O && ./Bar
True
I also kind of suspect -fexcess-precision
doesn't do anything for the native codegen (based on source code surfing), but it's hard to tell with this current bug.
Trac metadata
Trac field | Value |
---|---|
Version | 7.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |