gcc3 vs 176.gcc

[Dale Johannesen <dalej at apple dot com>]

The SPEC version of gcc (based on 2.7.2.2) contains this code:

typedef struct rtx_def {
   unsigned short code;  ... } *rtx;
....
   rt = (rtx)ob->object_base;
   length = (sizeof (struct rtx_def) - sizeof (rtunion) - 1) / sizeof (int)
;
   for (; length >= 0; length--)
     ((int *) rt)[length] = 0;	/* store #1 */
   ((rt)->code = (code));		/* store #2 */

When compiled with -fstrict-aliasing (currently turned on by -O2), this 
doesn't
work as expected on ppc Darwin (and probably elsewhere).  The aliasing info
for the two stores says they don't interfere, so the scheduler can invert
their order (depending on how registers get allocated).  I believe the code
above is undefined according to the standard (because of addressing a short
via (int*)), so gcc3 is within its rights here.  Still, it looks pretty 
silly
for gcc3 to be unable to build an earlier version of itself, and I want to
see if there's sentiment for doing something about it.

The two memrefs look like:

(insn 91 70 107 (set (mem:SI (reg:SI 4 r4 [117]) [26 S4 A32])
         (reg:SI 0 r0 [128])) 310 {*movsi_internal1} (insn_list 73 (nil))
     (expr_list:REG_DEAD (reg:SI 0 r0 [128])
         (nil)))

(insn 107 91 66 (set (mem/s:HI (reg:SI 4 r4 [117]) [55 <variable>.code+0 
S2 A64])
         (reg:HI 29 r29 [116])) 312 {*rs6000.md:8005} (nil)
     (expr_list:REG_DEAD (reg:HI 29 r29 [116])
         (expr_list:REG_DEAD (reg:SI 4 r4 [117])
             (nil))))

with the same base register and offset 0, as you see, so it really doesn't
take too much intelligence to figure out they interfere, at least in this 
case.

Could we change the aliasing check as follows?  First check for whether two
  memrefs are accessed off the same register(s); if they are, we know at 
once
  whether the memrefs interfere or not (depending on the offsets).  Only if
  the result of this check is indeterminate do we look at the aliasing info.

Could we decouple -fstrict-aliasing from -O2?  (Apple may well do this 
internally
  in any case, since technically incorrect casts like the one above seem to 
be
  fairly common in existing code.)