[GHC] #5165: GHC doesn't optimize FP excess precision properly
GHC
cvs-ghc at haskell.org
Fri Jul 13 13:18:30 CEST 2012
#5165: GHC doesn't optimize FP excess precision properly
------------------------------------------+---------------------------------
Reporter: ezyang | Owner:
Type: bug | Status: closed
Priority: low | Milestone: 7.6.1
Component: Compiler | Version: 7.1
Resolution: duplicate | Keywords:
Os: Linux | Architecture: x86
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
------------------------------------------+---------------------------------
Changes (by simonmar):
* status: new => closed
* difficulty: => Unknown
* resolution: => duplicate
Comment:
Closing as a dup of #7069; we now document this as a known bug.
Note that the particular example in this ticket also involves constant
folding, which we have to be careful to do at the correct precision. We
do make an attempt to do this properly, although it's not clear to me that
it really does the right thing, since we're relying on
{{{
toRational (fromRational (a `op` b))
}}}
being the same as
{{{
toRational (fromRational a `op` fromRational b)
}}}
which I rather doubt is the case. Here's the code from `PrelRules`:
{{{
-- When excess precision is not requested, cut down the precision of the
-- Rational value to that of Float/Double. We confuse host architecture
-- and target architecture here, but it's convenient (and wrong :-).
convFloating :: Literal -> Literal
convFloating (MachFloat f) | not opt_SimplExcessPrecision =
MachFloat (toRational ((fromRational f) :: Float ))
convFloating (MachDouble d) | not opt_SimplExcessPrecision =
MachDouble (toRational ((fromRational d) :: Double))
convFloating l = l
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5165#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list