[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 #9 from Vincent LefÃvre <vincent-srcware at vinc17 dot net> ---
(In reply to joseph@codesourcery.com from comment #8)
> There would be no reason for F.6 and F.10.11 (in C11) if the intent wasn't 
> to support evaluation in wider types.

The fact that both F.6 and F.10.11 are new in C11 shows that this is pointless
in C99. And I disagree about F.6: you can have

double foo (void)
{
  return LDBL_EPSILON;
}

int main (void)
{
  double x = 17.0L * foo ();
}

I don't think that C99 mandates that LDBL_EPSILON be converted to double if the
eval method is implementation-defined (the arithmetic operations would be
correctly rounded as required by IEEE 754, possibly with an extended exponent
range, but the implementation could decide for C specific operations such as
function calls). F.6 in C11 makes the behavior explicit.

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.

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.

> DTS 18661-1 clarifies things further [...]

Well, it's more than clarification, it is based on IEEE 754-2008, whose
requirements are different from the old IEEE 754-1985 standard: the old
requirement I mentioned became obsoleted (replaced) by the use of formatOf
operations. But C99 and C11's Annex F is based on the old IEEE 754-1985
standard.

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