optimization/9052: in C code, "if" statement fails to execute if optimized

[Steven Bosscher]

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9052

A small test case for this PR is the following:

#define N 256

int
main (void)
{
  float r[N];
  int n;

  r[0] = 0;
  for (n = 1; n < N; n++)
    {
      r[n] = r[n - 1] * r[n - 1] - .125;

//    printf("%f\n",r[n]-r[n/2]);

      if (r[n / 2] == r[n])
	break;
    }

  printf ("%d\n", n);
  return 0;
}

I have tested this with two different GCC versions:

Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
gcc version 2.95.3 20010315 (SuSE

Reading specs from
/opt/experimental/lib/gcc-lib/i586-pc-linux-gnu/3.4/specs
Configured with: ../gcc-trunk/configure --disable-nls --with-gnu-as
--with-gnu-ld --prefix=/opt/experimental --program-suffix=-3.4
--enable-languages=c
Thread model: posix
gcc version 3.4 20030211 (experimental)

Output from this testcase:
gcc version:	at -O0		at -O1		at -O2
2.95.3		 22		 22		 22
3.4 exp.	 22		256		256

After uncommenting the printf, gcc 3.4 also prints 22 at -O1 and -O2.

I have looked for documentation about this change in behavior but it
doesn't seem to exist. I'm not a floating point specialist, but
generally, comparing floats for equality doesn't seem like the best
thing to do.  However, since it apparently worked with older gcc
versions, I suppose one could qualify this as a regression...

Eric, I CC'ed you as the Great C Bug Squasher.  Do you think this is a
regression, and if so, change the status in GNATS?

Greetz
Steven