[cfe-dev] APFloat::toString() handling of MS FLT_MAX and DBL_MAX

[Eli Friedman]

Done in r189624.  (APFloat::toString really needs another look from someone
who's really an expert at floating-point stuff, but at least the default
behavior is sane.)

-Eli

On Tue, Aug 27, 2013 at 9:53 AM, Will Wilson <will at indefiant.com> wrote:

> I ended up with some nasty hacks to work around this issue, so if someone
> can fix it I'd be eternally grateful.
>
>
> On 27 August 2013 02:19, Jordan Rose <jordan_rose at apple.com> wrote:
>
>> I just hit this myself (months later!) trying to round-trip floats
>> through strings. I don't think the problem is printed values exceeding
>> their maximums so much as that APFloat::toString thinks the natural
>> precision for DBL_MAX is one digit shorter than it actually is. I'll take a
>> look, but someone with more floating-point experience might be able to get
>> to the bottom of this sooner.
>>
>> Jordan
>>
>>
>> On Apr 16, 2013, at 8:54 , Will Wilson <will at indefiant.com> wrote:
>>
>> Sorry, I'm not being clear enough. It's nothing to do with runtime libs.
>> Rather it's the result of printing out the expanded literal value directly
>> from the AST. For instance:
>>
>>    - Clang parses the DBL_MAX macro into the AST (defined
>>    as 1.7976931348623158e+308)
>>    - Pretty printing out the FloatingLiteral results in:
>>    1.797693134862316E+308
>>    - Feeding these literals back to MSVC results in: error C2177:
>>    constant too big
>>
>> So my question is: Would it be sensible to try and ensure the printed
>> values never exceed their maximums?
>>
>> Cheers,
>> Will.
>>
>>
>> On 16 April 2013 00:56, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>>
>>> On Apr 16, 2013 8:01 AM, "Will Wilson" <will at indefiant.com> wrote:
>>> >
>>> > Hi All,
>>> >
>>> > I'm rewriting MS C++ code via clang and have an issue involving the
>>> printed representations of FLT_MAX and DBL_MAX. In both cases the printed
>>> literals exceed the inputs.
>>> >
>>> > From MS float.h:
>>> >
>>> > #define DBL_MAX         1.7976931348623158e+308
>>> > // Becomes 1.797693134862316E+308
>>> >
>>> > #define FLT_MAX         3.402823466e+38F
>>> > // Becomes 3.4028235E+38F
>>> >
>>> > Rewriting the values leads to compilation errors due to the literals
>>> exceeding their maximums. This doesn't altogether surprise me given the
>>> nature of FP arithmetic and string conversion but I was wondering if this
>>> could/should be treated as a bug given the significance of these values?
>>>
>>> How are you printing these values out? Libstdc++ or libc++? Does the
>>> behavior reproduce under GCC too? I could guess/assume a bug in the
>>> standard library implementation you are using, but that's just a guess
>>>
>>> >
>>> > - Will.
>>> >
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> >
>>>
>>
>>
>>
>> --
>> *Indefiant Ltd.*
>> *
>> *
>> Firsby Lodge, New Main Road, Scamblesby, Louth, Lincs LN11 9XH UK
>> *Tel: +44 20 8123 7663 England Registered No. 07936820 VAT No. **
>> 128556202*
>>  _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>
>
> --
> *Indefiant Ltd.*
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130829/806918f1/attachment.html>