https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78189
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2016-11-03
Known to work| |4.9.4
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |5.5
Summary|movaps generated for |[5/6/7 Regression] movaps
|unaligned store in aligned |generated for unaligned
|struct, when struct is |store in aligned struct,
|referenced via unaligned |when struct is referenced
|member. |via unaligned member.
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine. Looks like we are confused by the MEM_REF offset:
MEM[(struct B *)misalignedPtr_1(D) + -8B].a.a
DR_BASE_ADDRESS is misalignedPtr_1, DR_INIT (used as 'misalign') is 16(OVF)
and DR_ALIGNED_TO is 128. That looks good but then we go:
/* To look at alignment of the base we have to preserve an inner MEM_REF
as that carries alignment information of the actual access. */
base = ref;
while (handled_component_p (base))
base = TREE_OPERAND (base, 0);
if (TREE_CODE (base) == MEM_REF)
base = build2 (MEM_REF, TREE_TYPE (base), base_addr,
build_int_cst (TREE_TYPE (TREE_OPERAND (base, 1)), 0));
unsigned int base_alignment = get_object_alignment (base);
and that computes an aligned base (but doesn't factor in the misalignment
from the MEM_REF offset we just stripped).
