[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419 --- Comment #4 from Hans-Peter Nilsson --- (In reply to rguent...@suse.de from comment #3) > 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'd assume alert target maintainers will notice and take action. > I agree that using target lists is imperfect (but it has the lowest > testsuite time overhead). JFTR, I'd say lower maintenance time beats lower test-run time ;) and the attribute is suitable for caching. But now that it's there I'd probably also just pile-on. > 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. It seems you already did this in your patch, that's right, thanks!
[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
--- Comment #3 from 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 ---
>
> (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.
[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
--- Comment #2 from Hans-Peter Nilsson ---
(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.
[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
Richard Biener 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 ---
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).
