On Sun, 19 Nov 2023, Jeff Law wrote: > > > On 11/19/23 00:30, Alexandre Oliva wrote: > > > > I've recently patched scev-3.c and scev-5.c because it only passed by > > accident on ia32. It also fails on some (but not all) arm-eabi > > variants. It seems hard to characterize the conditions in which the > > optimization is supposed to pass, but expecting them to fail on ilp32 > > targets, though probably a little excessive and possibly noisy, is not > > quite as alarming as getting a fail in test reports, so I propose > > changing the xfail marker from ia32 to ilp32. > > > > I'm also proposing to add a similar marker to scev-4.c. Though it > > doesn't appear to be failing for me, I've got reports that suggest it > > still does for others, and it certainly did for us as well. > > > > Regstrapped on x86_64-linux-gnu, also tested on arm-eabi with default > > cpu on trunk, and with tms570 on gcc-13. Ok to install? > > > > > > for gcc/testsuite/ChangeLog > > > > * gcc.dg/tree-ssa/scev-3.c: xfail on all ilp32 targets, > > though some of these do pass. > > * gcc.dg/tree-ssa/scev-4.c: Likewise. > > * gcc.dg/tree-ssa/scev-5.c: Likewise. > OK. Though hopefully someone will figure out what properties actually cause > the differences so that we can do the right thing without the noisy XPASS at > some point.
The tests all test IVOPTs induction variable selecting results (assuming every target would come to the "obvious" conclusion), so it's probably not only target but also sub-target (aka -mtune) sensitive ... In the end we might need to move/duplicate the test to some gcc.target/* dir and restrict it to a specific tuning. Richard.
