This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/69909] [6 Regression] wrong code with -Os and vectors @ x86_64
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 23 Feb 2016 13:05:36 +0000
- Subject: [Bug middle-end/69909] [6 Regression] wrong code with -Os and vectors @ x86_64
- Auto-submitted: auto-generated
- References: <bug-69909-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69909
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #10)
> On Tue, 23 Feb 2016, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69909
> >
> > --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > The wrong alias set appears in expr.c:10524
> > if (op0 == orig_op0)
> > op0 = copy_rtx (op0);
> >
> > set_mem_attributes (op0, exp, 0); /// <<<<< HERE
> >
> > if (REG_P (XEXP (op0, 0)))
> > mark_reg_pointer (XEXP (op0, 0), MEM_ALIGN (op0));
> >
> > Before that op0 has the right alias set from expansion:
> > (mem:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> > (const_int -48 [0xffffffffffffffd0])) [1 S16 A128])
> > but after this
> > (mem/j/c:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> > (const_int -48 [0xffffffffffffffd0])) [2 S16 A128])
> > Alias set 1 is TYPE_ALIAS_SET of the V vector, 2 is TYPE_ALIAS_SET of the U
> > vector.
> > exp here is:
> > debug_generic_stmt (exp)
> > BIT_FIELD_REF <_7, 128, 128>;
> > where:
> > _7 = VIEW_CONVERT_EXPR<U>(d.1_6);
> > I'd say that VIEW_CONVERT_EXPR expansion should make sure if it returns a MEM_P
> > that MEM_KEEP_ALIAS_SET is set on it at least if the TYPE_ALIAS_SET of the type
> > is different from MEM_ALIAS_SET.
> > And then BIT_FIELD_REF (and other handled_component_p expansion) should honor
> > MEM_KEEP_ALIAS_SET (or should that be set_mem_attributes_minus_bitpos itself),
> > and not adjust the alias set of the MEM.
>
> Nah, the thing to notice here is that
>
> BIT_FIELD_REF <_7, 128, 128>;
>
> is not a memory reference and thus set_mem_attributes should never
> derive any memory attributes from it
That is, this has nothing to do with VIEW_CONVERT_EXPRs, even if there were
no VCE but _7 were defined as
_7 = MEM[(XXX *)p_1 + ...];
that BIT_FIELD_REF may not be used to set mem attributes on the MEM expanded
for _7.