[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 #33 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
I couldn't find a failing test with FP contraction, but this seems to be
because GCC doesn't optimize as much as it could. Still, the following example
could be interesting in the future or as a non-regression test:

#include <stdio.h>

#define A 0x0.ffffffffffffp25
#define C -0x1.p50

int main (void)
{
  volatile double a = A;
  double b = a, c = C;
  int i;

#if 0
  double x = b * b;
  printf ("%a\n", x);
#endif
  // if (b == A && c == C)
  {
    i = b * b + c;
    printf ("%d\n", i);
    if (b == A && c == C)
      {
        // i = b * b + c;
        printf ("%d\n", i == -7);
      }
  }
  return 0;
}

By "GCC doesn't optimize as much as it could", I mean that the comparison with
-7 is generated, even though the result of this comparison is known at compile
time. Note that this is shown by the fact that uncommenting the second "i = b *
b + c;" does not change anything: a comparison with -7 is still generated.

With contraction enabled, one currently gets:

-7
1

(which is correct). If one uncomments the first "if (b == A && c == C)", one
gets:

-8
0

(still correct) showing that contraction is disabled at compile time.

Changing the "#if 0" to "#if 1" allows one to avoid contraction at run time.
Such a change can be useful if the rule at compile time changes in the future,
say: contraction is not used at run time, but at compile time, the optimization
bug might have the effect to re-evaluate i with contraction, yielding
inconsistent output.