[Bug middle-end/114347] wrong constant folding when casting __bf16 to int

["eggert at cs dot ucla.edu" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Paul Eggert <eggert at cs dot ucla.edu> ---
(In reply to Jakub Jelinek from comment #6)
> You can use -fexcess-precision=16 if you don't want treating _Float16 and
> __bf16 as having excess precision.  With excess precision, I think the above
> behavior is correct.

So the constant 257.0bf16 has a value that the type __bf16 cannot represent?
Although the C standard allows this sort of thing, it doesn't sound wise.

For example, it breaks a common use of 'typeof' that is given in the GCC manual
section 6.7 "Referring to a Type with 'typeof'". In this program:

  #define MAX(a, b) ((a) > (b) ? (a) : (b))
  #define max(a, b) \
    ({ typeof (a) _a = (a); \
       typeof (b) _b = (b); \
       _a > _b ? _a : _b; })

  int main (void)
  {
    return    max(257.0bf16, 256.0bf16)
           == MAX(257.0bf16, 256.0bf16);
  }

'main' surprisingly returns 0 when I expect pretty much everybody would expect
it to return 1. This is because "max" surprisingly changes the values of its
arguments before comparing, whereas MAX does not.

If GCC's "bf16" and "f16" suffixes arranged for floating point constants to be
representable as __bf16 and _Float16, respectively, we wouldn't have this sort
of confusion. Surely that would be better than the current situation.