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

["vincent-srcware at vinc17 dot net" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #11 from Vincent LefÃvre <vincent-srcware at vinc17 dot net> ---
(In reply to joseph@codesourcery.com from comment #10)
> I don't see what problems you see with any example code in Annex F

After looking at them more closely, they seem to be OK (in particular, for the
round() one, I forgot that the rounding mode was set toward zero, so that
double rounding effect couldn't occur).

But if rounding is always done to extended precision, there's still a
contradiction with the IEEE 754-1985 standard, which says: "Normally, a result
is rounded to the precision of its destination. However, some systems deliver
results only to double or extended destinations. On such a system the user,
which may be a high-level language compiler, shall be able to specify that a
result be rounded instead to single precision, though it may be stored in the
double or extended format with its wider exponent range. [FOOTNOTE 4: Control
of rounding precision is intended to allow systems whose destinations are
always double or extended to mimic, in the absence of over/underflow, the
precisions of systems with single and double destinations. An implementation
should not provide operations that combine double or extended operands to
produce a single result, nor operations that combine double extended operands
to produce a double result, with only one rounding.] Similarly, a system that
delivers results only to double extended destinations shall permit the user to
specify rounding to single or double precision. Note that to meet the
specifications in 4.1, the result cannot suffer more than one rounding error."

Basically, this means that on such a system, a language should either always
round to the precision of the semantic type or specify a function to allow the
user to select the rounding precision (rounding accuracy); but C doesn't
specify such a function.

> > 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.

This is about the precision (of the format), not the accuracy. For instance,
with the x87 FPU control word, even though the precision of the destination is
always 64 bits, the rounding accuracy[*] can be set to 24, 53 or 64 bits, as
required by IEEE 754.

[*] That's a more proper term than precision in this context.

> 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).

But the IEEE 754 standard requires it to be supported (see citation above).

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