[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array

["rsandifo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-07-27 12:46 -------
It'll come as no surprise that this is yet another bug related
to the infamous RTX_UNCHANGING_P.  A reduced C testcase is:

    extern void abort (void);
    void f (const char *x)
    {
      if (x[0] + x[1] + x[2] != 6)
	abort ();
    }
    int main()
    {
      { struct { int x : 31; char y[5]; } s; s.x = 1; }
      { const char x[] = { 1, 2, 3 }; f (x); }
      return 0;
    }

which fails on 3.4 branch for i686-pc-linux-gnu when compiled with
"-O2 -fno-strict-aliasing".  The problem is that 's.x' and 'x[]'
are both stored in the same 32-bit stack slot and that accesses
to 'x[]' are marked as unchanging (== "set once"):

    (insn 18 17 19 (set (mem/s/j:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
		    (const_int -16 [0xfffffff0])) [0+0 S4 A128])
	    (reg:SI 58)) -1 (nil)
	(nil))
    ....
    (insn 25 24 26 (set (mem/s/u:QI (plus:SI (reg/f:SI 54 virtual-stack-vars)
		    (const_int -16 [0xfffffff0])) [0 x+0 S1 A128])
	    (const_int 1 [0x1])) -1 (nil)
	(nil))

The scheduler thinks that the two stores don't conflict and decides
to swap them around.

When using -fstrict-aliasing, the variables will be put into different
stack slots and the bug does not occur.  This is because can only use
the same stack slot for two decls if objects_must_conflict_p says that
accesses to them will always conflict.  Strict aliasing puts 's'
and 'x' into different alias sets, so objects_must_conflict_p will
return false.

There aren't separate alias sets when using -fno-strict-aliasing,
so objects_must_conflict_p lets us assign both decls to the same slot.

In a nutshell, the problem seems to be that we're setting RTX_UNCHANGING_P
based on the properties of a decl but reusing stack slots based on the
properties of a type.  (Note that objects_must_conflict_p operates on
types rather than decls.)

Since RTX_UNCHANGING_P is no more (yay), this bug should be specific to 3.4.
I'm really not sure what the best fix there would be.  Perhaps we could
just get objects_must_conflict_p to return false for arrays of constant
elements, much like it does for structures with constant fields?

Richard

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-27 12:46:09
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129