https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69909
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- 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
