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 ...
FalseThe 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
TrueI 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 |