[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232

[rguenther at suse dot de]

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.