https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to jos...@codesourcery.com from comment #3) > I believe this is correct for C99 (see the discussions in bug 82071): [...] Bug 82071 has no discussions. The main reference is N1531, which one can find at: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1531.pdf but this is actually a clarification of potentially ambiguous text in C99. C99 6.3.1.8p2 says: "The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby." Thus, in the example, even though one has an implicit conversion of unsigned long long to double, the result may be represented in greater precision, and this is where FLT_EVAL_METHOD is taken into account. Note that there is an error in N1531, which says "6.3.1.8 (Usual arithmetic conversions) refers to conversions of operands of a floating type to another floating type." This is wrong! 6.3.1.8 also covers integer types; it actually uses the term "real type", and C99 defines it as "The integer and real floating types are collectively called real types." i.e. this includes integer types. There must have been a confusion by the authors of N1531. Then, the issue is whether 6.3.1.8 covers semantic types or evaluation types when considering the values. Considering the semantic types would defeat the purpose of the possibility to have an intermediate greater precision. Indeed, consider a, b and c of type double, and the floating-point expression (a + b) + c The result of a + b has semantic type double, like c. Using 6.3.1.8p1 "Otherwise, if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double.", the result of a + b would have to be converted to double, thus removing the extra precision and range. In short, either you should always do the conversion of the value to the semantic type for each implicit conversion (though this is clearly not the intent), or you should do the conversion to the evaluation type. But be consistent.
