https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92925
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-01-08
CC| |ebotcazou at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We're supposed to use get_object_alignment to set MEM_ALIGN and we do in most
of the cases (IIRC). So this must be an omission somewhere. So we indeed
compute that but then we called set_mem_attributes_minus_bitpos with
bptr_5(D)->a[i_11] but bitpos 64 - this seems to be a disconnect between
the callers using get_inner_reference to decompose a ref but then still
passing down the full ref tree to set_mem_attributes_minus_bitpos.
(gdb) up
#1 0x0000000000c969cf in expand_assignment (to=<array_ref 0x7ffff68180a8>,
from=<constructor 0x7ffff6960108>, nontemporal=false)
at /tmp/trunk2/gcc/expr.c:5357
5357 set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
indeed to_rtx doesn't have bitpos applied yet but
set_mem_attributes_minus_bitpos
says the offset is outstanding for 'T' (to). From a look at the function
it seems that it really applies to 'T', not to 'REF' so changing the above
caller to pass zero looks appropriate to me but it doesn't seem to help the
testcase either, likely alignment is mangled during the actual store emission.
Eric?
