From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32029 invoked by alias); 16 Oct 2008 08:16:13 -0000 Received: (qmail 31372 invoked by alias); 16 Oct 2008 08:14:51 -0000 Date: Thu, 16 Oct 2008 08:16:00 -0000 Message-ID: <20081016081451.31371.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01056.txt.bz2 ------- Comment #11 from rguenther at suse dot de 2008-10-16 08:14 ------- Subject: Re: [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize On Thu, 16 Oct 2008, spop at gcc dot gnu dot org wrote: > ------- Comment #10 from spop at gcc dot gnu dot org 2008-10-16 00:02 ------- > Subject: Re: [4.4 Regression] gcc-4.4 regression: incorrect code generation > with -O1 -ftree-vectorize > > On Wed, Oct 15, 2008 at 4:47 PM, rguenth at gcc dot gnu dot org > > IMHO the fix for the tuplification bug(!) is to strip the ADDR_EXPR that is > > always present on op0 in split_constant_offset_1 so: > > > > case ADDR_EXPR: > > { > > tree base, poffset; > > HOST_WIDE_INT pbitsize, pbitpos; > > enum machine_mode pmode; > > int punsignedp, pvolatilep; > > > > op0 = TREE_OPERAND (op0, 0); > > if (!handled_component_p (op0)) > > return false; > > This is exactly what I tried within gdb and it did worked, although > not as I expected: the base address ends to be &s and not &s.c[0] as > I expected before. This then fixes the bug as we end on the same > base address of the structure. Then the alias analysis answers that > the two accesses can overlap. Yes, but that is another thing. It also isn't that simple - for any two accesses you want to disambiguate you have to find a suitable common base. Consider &s.c[1] and &s + i, obviously the accesses can overlap - would you still say so if the base address of the first one would be &s.c[0]? (really the base address of a non-variable access is the access itself, right? &s.c[1] in this case) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573