Re: [RFT] fwprop merge

[Steven Bosscher <steven dot bosscher at gmail dot com>]

On Friday 19 May 2006 00:36, Steven Bosscher wrote:
> * 5 are testsuite/gcc.c-torture/execute/20040709-2.c at -O2 and higher
>   (m32r:4 execution, 1*m68hc11:1 execution, but it didn't compile before).

I've been fighting this one all weekend, using m32r as a testing target.
But I really did not see what was going wrong.  I tried really *really*
hard to find some place in fwprop to blame, but there really isn't any
thing I could see that it was not doing right.

Then I disabled CSE path following on an otherwise unpatched compiler...

Lo and behold, the test cases failed.  With the _unpatched_ compiler
except that CSE path following is disabled.  Somehow CSE path following
makes the test case below "work" at -O2 and higher.  With CSE path
following disabled, the attached test case fails.  The original test
case fails at -O3 only because it needs -finline-functions.

It seems to me that no test case should depend on optimizations being
enabled to make them work, so I'm not going to consider this as an fwprop
bug.

Something for an m32r maintainer to pick up, I suppose...?

Gr.
Steven



extern void abort (void);
extern void exit (int);

struct __attribute__ ((packed)) B
{
  unsigned short i:4, j:1, k:11;
  unsigned int l;
};

static struct B sB;

static struct B
retmeB (struct B x)
{
  return x;
}

void __attribute__((noinline))
testB (void)
{
  int i;
  unsigned int mask, r;
  struct B x, y;

  sB.l = 5.25;
  sB.k = -1;
  mask = sB.k;

  sB.k = 1902;

  x = sB;

  y = sB;
  y.k = y.k + 1902;
  y = retmeB (y);
  r = y.k;

  printf ("results say: %d %d %d\n", x.i != sB.i, x.l != sB.l, (3804 & mask) != r);
  if (x.l != sB.l)
    abort ();

  sB.k = 1902;
  x = sB;
  printf ("result says: %d %d\n", x.l != sB.l);
  if (x.l != sB.l)
    abort ();
}

int
main (void)
{
  testB ();
  exit (0);
}