[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #27 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to jos...@codesourcery.com from comment #26)
> I wouldn't be surprised if such a test could be constructed in the absence 
> of -funsafe-math-optimizations, that does a single conversion of an 
> out-of-range integer to a floating-point type in the abstract machine but 

I suppose that you meant the opposite: floating-point to integer.

> where that conversion gets duplicated so that one copy is done at compile 
> time (valid with -fno-trapping-math, covered by other bugs in the 
> -ftrapping-math case where it loses exceptions) and the other copy is done 
> at run time and the particular instruction used doesn't follow the logic 
> in fold_convert_const_int_from_real of converting NaN to zero and 
> saturating other values.

Yes, here's an example:

#include <stdio.h>

__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }

int main (void)
{
  double x = opaque(5000000000.0);
  int i;

  i = x;
  printf ("%d\n", i);
  if (x == 5000000000.0)
    printf ("%d\n", i);
  return 0;
}

With -O3, I get:

-2147483648
2147483647

Tested with:

gcc-10 (Debian 10-20200222-1) 10.0.1 20200222 (experimental) [master revision
01af7e0a0c2:487fe13f218:e99b18cf7101f205bfdd9f0f29ed51caaec52779]