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

[rguenther at suse dot de]

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

--- Comment #31 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 25 Feb 2020, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
> 
> --- Comment #28 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> A slightly modified version of the example, showing the issue with GCC 5 to 7
> (as the noipa attribute directive has been added in GCC 8):
> 
> #include <stdio.h>
> 
> int main (void)
> {
>   volatile double d = 5000000000.0;
>   double x = d;
>   int i = x;
> 
>   printf ("%d\n", i);
>   if (x == 5000000000.0)
>     printf ("%d\n", i);
>   return 0;
> }
> 
> The -O1 optimization level is sufficient to make the bug appear.

it's DOM at work with conditional equivalences again:

Optimizing statement if (x_3 == 5.0e+9)
LKUP STMT x_3 eq_expr 5.0e+9
Optimizing block #3

1>>> STMT 1 = x_3 ordered_expr 5.0e+9
1>>> STMT 1 = x_3 le_expr 5.0e+9
1>>> STMT 1 = x_3 ge_expr 5.0e+9
1>>> STMT 1 = x_3 eq_expr 5.0e+9
1>>> STMT 0 = x_3 ne_expr 5.0e+9
0>>> COPY x_3 = 5.0e+9
Match-and-simplified (int) x_3 to 2147483647
0>>> COPY i_4 = 2147483647
Optimizing statement printf ("%d\n", i_4);
  Replaced 'i_4' with constant '2147483647'