https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69909
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rguent...@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.
