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

[Will Wilson]

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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130827/6b624cff/attachment.html>