[Bug c/87390] [x86 32bit only] GCC does not honor FLT_EVAL_METHOD on implicit conversion of integer to floating point

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390

--- Comment #23 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to joseph@codesourcery.com from comment #22)
> 6.3.1.8 specifies *types*.  It only gives some partial information about 
> *evaluation formats*, which is essentially a consequence of information 
> elsewhere (it states the possibility of wider evaluation formats, while 
> never requiring them to be used, and states that when they are used they 
> don't affect the types).

No, this does not reflect the historical practice. Information in 6.3.1.8
predates information you can find elsewhere. You can see a C89 draft here:

https://port70.net/~nsz/c/c89/c89-draft.html

3.2.1.5 Usual arithmetic conversions[*]

(which was the old 6.3.1.8) already has: "The values of operands and of the
results of expressions may be represented in greater precision and range than
that required by the type; the types are not changed thereby." but information
you can now find in 5.2.4.2.2 is not present (in particular, FLT_EVAL_METHOD
does not exist).

[*] https://port70.net/~nsz/c/c89/c89-draft.html#3.2.1.5 

> I think 5.2.4.2.2 has the main specification of 
> when wider evaluation formats are used.

It completes information from 6.3.1.8. But if FLT_EVAL_METHOD = -1, this is
just like old C89 behavior and its clause 3.2.1.5 (corresponding to 6.3.1.8 in
C99).

> I think the combined effect of 
> 5.2.4.2.2 and 6.3.1.5 is that the particular form of implicit conversion 
> involved in the usual arithmetic conversions does not *remove* excess 
> range and precision from an operand to an operator that applies the usual 
> arithmetic conversions, but that this does not result in excess precision 
> being *introduced* by such an implicit conversion when the argument was of 
> integer type, in the absence of any explicit wording providing for such 
> conversions to result in a value with excess precision.

5.2.4.2.2p8 does not have specific rules for integer types. It says "[...]
values subject to the usual arithmetic conversions [...] are evaluated to a
format whose range and precision may be greater than required by the type."
This is quite clear: values subject to the usual arithmetic conversions can
either be floating-point values or integer values, as described in "6.3.1.8
Usual arithmetic conversions". And for FLT_EVAL_METHOD = 2, the format in
question is long double.