Should rand() return a RAND_MAX value for 32 bit target?

[Vincent Lefevre]

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@vinc17.net> - 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)