[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=6981

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 7 Feb 2014, vincent-srcware at vinc17 dot net wrote:

> Concerning F.10.11, there's a contradiction with some codes given earlier in
> Annex F, which assume FLT_EVAL_METHOD to be 0 or a value with
> implementation-defined behavior.

I don't see what problems you see with any example code in Annex F (but in 
any case, if there are contradictions - which you should raise as C11 DRs 
if so - it's natural to try to resolve them in accordance with the clear 
intent that FLT_EVAL_METHOD being 2 is consistent with Annex F.

> Now, it is not even clear that the following would be forbidden:
> FLT_EVAL_METHOD is 1 or 2, but rounding for the arithmetic operations is done
> in the semantic type. For instance, I suspect that FLT_EVAL_METHOD should be 2
> with the x87 FPU, even when configured to round to double precision, because
> the intermediate values still have the extended exponent range (unless the
> compiler chooses to store the intermediate values to memory). In the C
> standard, FLT_EVAL_METHOD = 2 doesn't imply that the full extended precision is
> used, just that the intermediate values are representable in long double.

"evaluate all operations and constants to the range and precision of the
long double type" seems clear enough to me.

If the x87 FPU is rounding to double precision, that's a different ABI, as 
used on 32-bit FreeBSD, where long double has the extended-precision 
in-memory encoding but only 53 mantissa bits are used; that ABI isn't 
supported by glibc (calling libm functions with the FPU rounding to double 
precision means undefined behavior).

-- 
You are receiving this mail because:
You are on the CC list for the bug.