This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array
- From: "rsandifo at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Jul 2005 12:46:12 -0000
- Subject: [Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array
- References: <20050620202450.22129.cnewbold@mathworks.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot 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