🚀 go-pugleaf

Sir,

  Optimalization seems to mishandle the order of statements when indirection,
  postfix increment, and floating point numbers are involved.  The skeleton
  program which follows below succeeds without, but fails after optimalization.
  The much larger program I'm actually working on retains the bug if I
  do without optimalization, however.  That bothers me. 

  Skeleton program:

#include <stdio.h>

main()
{
 int	r[7];
 float	a[] = {5, 1, 3, 5, 9, 1, 7};
 float 	b[] = {2, 4, 3, 0, 3, 1, 3};
 float  *x, *y;
 int	*d, n, *c;

 x = a; y = b; c = r; d = c; n = 7;
 while (n) {*c++ = *x++ == *y++; n--;}
 for (n = 0; n<7; n++) printf("%d ", d[n]); printf("\n");
 return;
}

  This was compiled on a DECstation 5000/200 under Ultrix, using
  version 2.2.2 (as far as I can tell) of GNU CC.

  gcc -o test test.c; test
   yields  0 0 1 0 0 1 0, which was expected, whereas
  gcc -O -o test test.c; test
   yields  0 1 0 0 1 0 1.

  I have not been able to find out which kinds of optimalization are
  standard on this system.

  If all instances of the word "float" are replaced with "int", then
  the proper result is returned both in the optimized and the non-optimized
  cases.  "double" shows the same results as "float".

  Changing the relevant code to
  {l = *x++ == *y++; *c++ = l; n--}
  or
  {*c = *x++ == *y++; c++; n--}
  does not remove the bug; I assume this generates optimized code identical
  to the original.
  
  Changing the code to
  {*c++ = *x == *y; x++; y++; n--;}
  does yield the expected result.

  These and some other rewrites using deferred pointer increments are
  consistent with the pointer increment - for pointers to non-integer only -
  being done before the value it references is retrieved, instead of the
  other way around, as C syntax prescribes.

  Regards,

  Louis Strous
  Astronomical Department
  Utrecht University
  The Netherlands