From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1175 invoked by alias); 27 Jul 2005 12:46:22 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1141 invoked by uid 48); 27 Jul 2005 12:46:12 -0000 Date: Wed, 27 Jul 2005 12:50:00 -0000 Message-ID: <20050727124612.1140.qmail@sourceware.org> From: "rsandifo at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050620202450.22129.cnewbold@mathworks.com> References: <20050620202450.22129.cnewbold@mathworks.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array X-Bugzilla-Reason: CC X-SW-Source: 2005-07/txt/msg03523.txt.bz2 List-Id: ------- 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