[GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity

[GHC]

#15271: 1e1000000000 :: Double yields 0.0 instead of Infinity
-------------------------------------+-------------------------------------
        Reporter:  claude            |                Owner:  fangyizhou
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D5271
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"8e1a5593f940b9d2882a5e81abf028e7b99aff3a/ghc" 8e1a559/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="8e1a5593f940b9d2882a5e81abf028e7b99aff3a"
 Fix integer overflow when encoding doubles (Trac #15271)

 Summary:
 Ticket #15271 reports a case where 1e1000000000 is incorrectly
 converted to 0.0. After some investigation, I discovered the number is
 converted to rational correctly, but converting the ratio into a double
 introduced an error.

 Tracking down to how the conversion is done, I found the rts float
 implementation uses `ldexp`, whose signature is
 `double ldexp (double x, int exp);`
 The callsite passes an `I_` to the second argument, which is
 platform-dependent. On machines where `I_` is 64 bits and `int` is 32
 bits, we
 observe integer overflow behaviour.

 Here is a mapping from rational to exponent with observations
 1e646457008  -> 2147483645 (result = infinity, positive in int32)
 1e646457009  -> 2147483648 (result = 0.0, overflow to negative in int32)
 1e1000000000 -> 3321928042 (result = infinity, overflow to positive in
 int32)
 1e1555550000 -> 5167425196 (result = 0.0, overflow to negative in int32)

 We fix this issue by comparing STG_INT_MIN/MAX and INT_MIN/MAX and bound
 the
 value appropriately.

 Test Plan: New test cases

 Reviewers: bgamari, erikd, simonmar

 Reviewed By: bgamari

 Subscribers: rwbarton, carter

 GHC Trac Issues: #15271

 Differential Revision: https://phabricator.haskell.org/D5271
 }}}

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15271#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler