https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 12 Aug 2019, hp at gcc dot gnu.org wrote: > 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)? No, usually type-based alias rules forbid this (-fstrict-aliasing). But relying on that proved difficult/impossible for the value-numbering feature tested by these testcases so we now rely solely on alignment... > > 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. OK, so all testcases in this PR use 'int' which means disabling for !natural_alignment_32 would be enough (unless 'int' is not 32bit ;)) I agree that using target lists is imperfect (but it has the lowest testsuite time overhead). I'll amend the testcases with xfails for !natural_alignment_32. Can you amend the target lists appropriately? I guess cris-*-* (not only cris-*-elf) would need to be added.
