[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 gcc-bugzilla@gcc.gnu.org
Wed Sep 26 19:33:00 GMT 2018


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

--- Comment #6 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to joseph@codesourcery.com from comment #5)
> It's 6.3.1.4 for conversions between real floating and integer types that, 
> in C99 but not C11, I think requires the resulting value to be 
> representable in the resulting real floating type.

No, it just requires the value to be in the range of values that can be
represented (which is always the case in practice, even though the C standard
does not forbid very long integers). Anyway, this is unrelated to the use of
extra precision and range.

Note that:
* 6.3.1.4 is about the behavior of conversion between real floating and
integer, for given types.
* 6.3.1.5 is about the behavior of conversion between real floating types, for
given types.
* 6.3.1.8 is about the selection of the arithmetic types (implicit
conversions).

Neither 6.3.1.4, nor 6.3.1.5 deals with semantic vs evaluation type (6.3.1.5
mentions "greater precision and range than required by its semantic type", but
*only* for the other direction, in an *explicit* conversion). It is 6.3.1.8
that deals with the rules about extra precision and range.

BTW, note 52 of 6.3.1.8 says "The cast and assignment operators are still
required to perform their specified conversions as described in 6.3.1.4 and
6.3.1.5." i.e. mentioning both 6.3.1.4 and 6.3.1.5, thus confirming that
implicit conversions of integer to real floating is also covered by the extra
precision and range (otherwise referencing 6.3.1.4 would be pointless). That
is, if d has type double,

  d + (1ULL << 63)

and

  d + (double) (1ULL << 63)

are handled differently.


More information about the Gcc-bugs mailing list