https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> 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.
Ew! I'd hope there was some language constraint forbidding such incomplete
overlap. Doesn't that mean a pointer to a structure can overlap another for
structures with piecewise similarity (for all targets)?
> 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?
Yes.
At r274275 for ipa.exp:
Running /x/autotestgcc1/gcc/gcc/testsuite/gcc.dg/ipa/ipa.exp ...
FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be
created; target is discardable"
FAIL: gcc.dg/ipa/propalign-1.c scan-ipa-dump cp "Adjusting align"
FAIL: gcc.dg/ipa/propalign-1.c scan-tree-dump-not optimized "fail_the_test"
FAIL: gcc.dg/ipa/propalign-2.c scan-ipa-dump cp "Adjusting align"
FAIL: gcc.dg/ipa/propalign-2.c scan-tree-dump-not optimized "fail_the_test"
FAIL: gcc.dg/ipa/propalign-5.c scan-ipa-dump cp "align: 2"
(These tests have failed at every auto-test-run, i.e. not regressions, i.e. I
haven't paid attention to them.)
> Does it make sense to have natural_alignment_16 (not sure about the targets
> you cite, but m68k would fall into this category).
For cris-elf there's byte alignment, not (u)int16_t-alignment, so I guess we'd
have to introduce another effective_target. But, I think it could better use a
compile-test and alignof as the default, rather than a target-list.
