On 2018-09-22 21:52:34 +0800, Liu Hao wrote: > 在 2018/9/22 18:08, Vincent Lefevre 写道: > > Bug reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390 > > (note that the tests do not involve constants, these are just about > > implicit type conversions). > > That's about contraction. No, FLT_EVAL_METHOD is not related to contraction. > The behavior in the OP can only be observed when no optimization is > enabled (i.e. with `-O0`) or when strict standard compliance is > requested (i.e. with `-std=c99` or `-ansi`) and no > `-ffp-contract=fast` is in effect. With the OP's program, I get False only when optimization is enabled and strict standard compliance is not requested (or equivalent). > It is irrelevant to this issue. It is: If FLT_EVAL_METHOD were honored for integer-to-float conversion, one should have never got True with strict standard compliance, because the value of f is exactly representable in a float and RAND_MAX isn't. > Contraction is about what happens within a floating-point operation, I'm not considering contraction, but FLT_EVAL_METHOD. > but in your program (the standard says) `2147483647` is converted to > type `float` before the floating-point comparison, This is the semantic type. But the evaluation type is long double. > so it behaves as if you had added a cast like `f == > (float)2147483647`. No, the standard says "Except for assignment and cast (which remove all extra range and precision), [...]", thus by adding the cast, you are changing the semantics. See the testcase I've posted to my bug report, and the parallel between (float) d + (float) 1.0 and i + 1 (both are converted to the semantic type double, but GCC's behavior is different on these two expressions). -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
