https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-08-12
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Jeff also noticed this. The issue should happen on targets where alignof(int)
!= sizeof(int) since there we cannot conclude that with int *p, *q; the
accesses *p and *q either overlap exactly (p == q) or they do not overlap.
Skimming through target-supports.exp I see natural_alignment_32 but that
seems to be incomplete, not matching either of the affected targets of this
bug:
# Return 1 if types of size 32 bit or less are naturally aligned
# (aligned to their type-size), 0 otherwise.
#
# This won't change for different subtargets so cache the result.
proc check_effective_target_natural_alignment_32 { } {
# FIXME: 32bit powerpc: guaranteed only if MASK_ALIGN_NATURAL/POWER.
return [check_cached_effective_target_indexed natural_alignment_32 {
if { ([istarget *-*-darwin*] && [is-effective-target lp64])
|| [istarget avr-*-*] } {
return 0
} else {
return 1
}
}]
}
Thus known issue but no easy testsuite workaround sofar unless we fix the
above. natural_alignment_32 is used in
gcc.dg/ipa/propalign-?.c
and some powerpc specific vector tests. Do the above also fail for you?
Does it make sense to have natural_alignment_16 (not sure about the targets
you cite, but m68k would fall into this category).
