https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--- Comment #20 from Paul Eggert <eggert at cs dot ucla.edu> ---
(In reply to jos...@codesourcery.com from comment #14)
> This is just the same as other unspecified things like converting an
> out-of-range value from floating-point to integer.
No, because when GCC's constant folding disagrees with machine arithmetic, GCC
can generate code that violates the relevant standards.
Here's an example taken from Bug 111655:
int
main ()
{
double x = 0.0 / 0.0;
return !__builtin_signbit (x) == !__builtin_signbit (-x);
}
'main' must return 0 no matter what x's sign happens to be, because "-x" must
flip x's sign bit, so __builtin_signbit(-x) must yield the opposite result from
__builtin_signbit(x). However, this code returns 1 with gcc (GCC) 13.2.1
20230728 (Red Hat 13.2.1-1) on x86-64, compiled with -O2.
The bug occurs because the evaluation of __builtin_signbit (x) is
constant-folded to 0 (under the assumption that 0.0/0.0 yields +NaN), whereas
the evaluation of __builtin_signbit (-x) iuses machine arithmetic to first
calculate 0.0/0.0 (i.e., -NaN), then negate that to +NaN, and then calculate
its sign bit to be 0.
At least for this particular example, GCC is generating the wrong code so this
bug report should be decorated with a "wrong-code" keyword.
