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).