[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

------- 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