* [PATCH] testsuite: scev: expect fail on ilp32 @ 2023-11-19 7:30 Alexandre Oliva 2023-11-19 15:12 ` Jeff Law 0 siblings, 1 reply; 17+ messages in thread From: Alexandre Oliva @ 2023-11-19 7:30 UTC (permalink / raw) To: gcc-patches; +Cc: Richard Biener, Rainer Orth, Mike Stump 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. --- gcc/testsuite/gcc.dg/tree-ssa/scev-3.c | 3 ++- gcc/testsuite/gcc.dg/tree-ssa/scev-4.c | 3 ++- gcc/testsuite/gcc.dg/tree-ssa/scev-5.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c index ac8c8d4519e30..beea9aed9fe95 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c @@ -40,4 +40,5 @@ __BB(6): } -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ +/* Not all 32-bit systems fail this, but several do. */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c index 57cb021340218..a97f75f81f654 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c @@ -45,4 +45,5 @@ __BB(6): } -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" } } */ +/* Not all 32-bit systems fail this, but several do. */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c index c911a9298866f..08f4260403c40 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c @@ -40,4 +40,5 @@ __BB(6): } -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ +/* Not all 32-bit systems fail this, but several do. */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-19 7:30 [PATCH] testsuite: scev: expect fail on ilp32 Alexandre Oliva @ 2023-11-19 15:12 ` Jeff Law 2023-11-20 7:35 ` Richard Biener 0 siblings, 1 reply; 17+ messages in thread From: Jeff Law @ 2023-11-19 15:12 UTC (permalink / raw) To: Alexandre Oliva, gcc-patches; +Cc: Richard Biener, Rainer Orth, Mike Stump 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. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-19 15:12 ` Jeff Law @ 2023-11-20 7:35 ` Richard Biener 2023-11-28 15:13 ` Rainer Orth 0 siblings, 1 reply; 17+ messages in thread From: Richard Biener @ 2023-11-20 7:35 UTC (permalink / raw) To: Jeff Law; +Cc: Alexandre Oliva, gcc-patches, Rainer Orth, Mike Stump 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-20 7:35 ` Richard Biener @ 2023-11-28 15:13 ` Rainer Orth 2023-11-29 18:00 ` Hans-Peter Nilsson 0 siblings, 1 reply; 17+ messages in thread From: Rainer Orth @ 2023-11-28 15:13 UTC (permalink / raw) To: Richard Biener; +Cc: Jeff Law, Alexandre Oliva, gcc-patches, Mike Stump Richard Biener <rguenther@suse.de> writes: > 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. FWIW, since Alexandre's patch all three tests XPASS on 32-bit Solaris/SPARC: XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-28 15:13 ` Rainer Orth @ 2023-11-29 18:00 ` Hans-Peter Nilsson 2023-11-30 4:41 ` Alexandre Oliva 0 siblings, 1 reply; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-11-29 18:00 UTC (permalink / raw) To: oliva; +Cc: rguenther, jeffreyalaw, Rainer Orth, gcc-patches, mikestump > From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> > Date: Tue, 28 Nov 2023 16:13:35 +0100 > Richard Biener <rguenther@suse.de> writes: > > > 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. > > FWIW, since Alexandre's patch all three tests XPASS on 32-bit > Solaris/SPARC: > > XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 > XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 > XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 It XPASSes on the ilp32 targets I've tried - except "ia32" (as in i686-elf) and h8300-elf. Notably XPASSing targets includes a *default* configuration of arm-eabi, which in part contradicts your observation above. I see it even XPASSes in H.J.'s x86_64-pc-linux-gnu -mx32 results. Right, that's not ia32, but it's as ilp32ish as ia32 and can be expected to share most "interesting" properties with ia32. Example report at https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801862.html. Alex, can you share the presumably plural set of targets where you found gcc.dg/tree-ssa/scev-[3-5].c to fail before your patch, besides "ia32"? I see them XPASS for: m68k-unknown-linux-gnu (https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801839.html) pru-unknown-elf (https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801732.html) and from my own testing, at r14-5608-g69741355e6dbcf: cris-elf, c6x-elf, epiphany-elf, ft32-elf, hppa-unknown-linux-gnu, lm32-elf, microblaze-linux, m32r-elf, arm-eabi. So, ilp32 is IMO a really bad approximation for the elusive property. Would you please consider changing those "ilp32" to a specific set of targets where these tests failed? I'd prefer not to complicate those expressions by adding the right spelling of "ilp32 except { list }". brgds, H-P ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-29 18:00 ` Hans-Peter Nilsson @ 2023-11-30 4:41 ` Alexandre Oliva 2023-11-30 8:32 ` Richard Biener 2023-11-30 17:09 ` Hans-Peter Nilsson 0 siblings, 2 replies; 17+ messages in thread From: Alexandre Oliva @ 2023-11-30 4:41 UTC (permalink / raw) To: Hans-Peter Nilsson, Eric Botcazou Cc: rguenther, jeffreyalaw, Rainer Orth, gcc-patches, mikestump On Nov 29, 2023, Hans-Peter Nilsson <hp@axis.com> wrote: >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 > It XPASSes on the ilp32 targets I've tried - except "ia32" > (as in i686-elf) and h8300-elf. Notably XPASSing targets > includes a *default* configuration of arm-eabi, which in > part contradicts your observation above. My arm-eabi testing then targeted tms570 (big-endian cortex-r5). I borrowed the ilp32 vs lp64 line from an internal patch by Eric that we've had in gcc-11 and gcc-12, when I hit this fail while transitioning the first and then the second of our 32-bit targets to gcc-13. Eric, would you happen to recall where the notion that lp64 was a good heuristic for these tests? > Alex, can you share the presumably plural set of targets > where you found gcc.dg/tree-ssa/scev-[3-5].c to fail before > your patch, besides "ia32"? I haven't even seen scev-4.c fail, I only got reports that it did. I'm not even claiming it fails, I'm only claiming it has been observed to fail on some ilp32 targets, and nobody seems to have a good sense of when it's supposed to pass or fail, so my reasoning was that making it an expected fail is less alarming than seeing actual failures on some targets. It was known to be imprecise, but to be an improvement over getting a FAIL for some reasonably common targets when there was no reason to expect it to actually pass, or even to have ever passed. > So, ilp32 is IMO a really bad approximation for the elusive > property. Yeah. Maybe we should just drop the ilp32, so that it's an unsurprising fail on any targets? > Would you please consider changing those "ilp32" to a > specific set of targets where these tests failed? I'd normally have aimed for that, but the challenge is that arm-eabi is not uniform in the results for this test, and there doesn't seem to be much support or knowledge to delineate on which target variants it's meant to pass or not. The test expects the transformation to take place, as if it ought to, but there's no strong reason to expect that it should. There's nothing wrong if it doesn't. Going about trying to match the expectations to the current results may be useful, but investigating the reasons why we get the current results for each target is beyond my available resources for a set of tests that used to *seem* to pass uniformly only because of a bug in the test pattern. I don't see much value in these tests as they are, TBH. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-30 4:41 ` Alexandre Oliva @ 2023-11-30 8:32 ` Richard Biener 2023-11-30 17:09 ` Hans-Peter Nilsson 1 sibling, 0 replies; 17+ messages in thread From: Richard Biener @ 2023-11-30 8:32 UTC (permalink / raw) To: Alexandre Oliva Cc: Hans-Peter Nilsson, Eric Botcazou, jeffreyalaw, Rainer Orth, gcc-patches, mikestump On Thu, 30 Nov 2023, Alexandre Oliva wrote: > On Nov 29, 2023, Hans-Peter Nilsson <hp@axis.com> wrote: > > >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 > >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 > >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 > > > It XPASSes on the ilp32 targets I've tried - except "ia32" > > (as in i686-elf) and h8300-elf. Notably XPASSing targets > > includes a *default* configuration of arm-eabi, which in > > part contradicts your observation above. > > My arm-eabi testing then targeted tms570 (big-endian cortex-r5). > > I borrowed the ilp32 vs lp64 line from an internal patch by Eric that > we've had in gcc-11 and gcc-12, when I hit this fail while transitioning > the first and then the second of our 32-bit targets to gcc-13. > > Eric, would you happen to recall where the notion that lp64 was a good > heuristic for these tests? > > > Alex, can you share the presumably plural set of targets > > where you found gcc.dg/tree-ssa/scev-[3-5].c to fail before > > your patch, besides "ia32"? > > I haven't even seen scev-4.c fail, I only got reports that it did. > > I'm not even claiming it fails, I'm only claiming it has been observed > to fail on some ilp32 targets, and nobody seems to have a good sense of > when it's supposed to pass or fail, so my reasoning was that making it > an expected fail is less alarming than seeing actual failures on some > targets. It was known to be imprecise, but to be an improvement over > getting a FAIL for some reasonably common targets when there was no > reason to expect it to actually pass, or even to have ever passed. > > > So, ilp32 is IMO a really bad approximation for the elusive > > property. > > Yeah. Maybe we should just drop the ilp32, so that it's an unsurprising > fail on any targets? > > > Would you please consider changing those "ilp32" to a > > specific set of targets where these tests failed? > > I'd normally have aimed for that, but the challenge is that arm-eabi is > not uniform in the results for this test, and there doesn't seem to be > much support or knowledge to delineate on which target variants it's > meant to pass or not. The test expects the transformation to take > place, as if it ought to, but there's no strong reason to expect that it > should. There's nothing wrong if it doesn't. Going about trying to > match the expectations to the current results may be useful, but > investigating the reasons why we get the current results for each target > is beyond my available resources for a set of tests that used to *seem* > to pass uniformly only because of a bug in the test pattern. > > I don't see much value in these tests as they are, TBH. As I said the tests are really testing IVOPTs costing which is target specific. Maybe we should move them to gcc.target/$X and figure what target they were originally intended to cover ... Richard. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-30 4:41 ` Alexandre Oliva 2023-11-30 8:32 ` Richard Biener @ 2023-11-30 17:09 ` Hans-Peter Nilsson 2023-12-01 2:38 ` Hans-Peter Nilsson ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-11-30 17:09 UTC (permalink / raw) To: Alexandre Oliva Cc: botcazou, rguenther, jeffreyalaw, ro, gcc-patches, mikestump > From: Alexandre Oliva <oliva@adacore.com> > Date: Thu, 30 Nov 2023 01:41:55 -0300 > On Nov 29, 2023, Hans-Peter Nilsson <hp@axis.com> wrote: > > >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 > >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 > >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 > > > It XPASSes on the ilp32 targets I've tried - except "ia32" > > (as in i686-elf) and h8300-elf. Notably XPASSing targets > > includes a *default* configuration of arm-eabi, which in > > part contradicts your observation above. > > My arm-eabi testing then targeted tms570 (big-endian cortex-r5). > > I borrowed the ilp32 vs lp64 line from an internal patch by Eric that > we've had in gcc-11 and gcc-12, when I hit this fail while transitioning > the first and then the second of our 32-bit targets to gcc-13. 'k, I interpret that as that ilp32 being mostly a copy-paste of unclear origin, and that there weren't actually any observation of more than two ilp32 targets failing (counting ia32 and one or more non-default armeb). > > So, ilp32 is IMO a really bad approximation for the elusive > > property. > > Yeah. Maybe we should just drop the ilp32, so that it's an unsurprising > fail on any targets? > > > Would you please consider changing those "ilp32" to a > > specific set of targets where these tests failed? > > I'd normally have aimed for that, but the challenge is that arm-eabi is > not uniform in the results for this test, and there doesn't seem to be > much support or knowledge to delineate on which target variants it's > meant to pass or not. That situation suggests to me to *skip* it for arm*-*-*. For other targets, skip or xfail as needed after a quick look. Or as per below. > The test expects the transformation to take > place, as if it ought to, but there's no strong reason to expect that it > should. There's nothing wrong if it doesn't. Going about trying to > match the expectations to the current results may be useful, but > investigating the reasons why we get the current results for each target > is beyond my available resources for a set of tests that used to *seem* > to pass uniformly only because of a bug in the test pattern. > > I don't see much value in these tests as they are, TBH. Richard B. seems to have been the last person doing significant work on those tests (rewriting scev-[3-5].c to gimple tests for ivopts, commit r7-6026-ga23e48df4514c4), so I value his suggestion per below particularly valuable: > > In the end we might need to move/duplicate the test to some > > gcc.target/* dir and restrict it to a specific tuning. I intend to post two alternative patches to get this resolved: 1: Move the tests to gcc.target/i386/scev-[3-5].c 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed only on h8300-*-* and ia32. If you can help with e.g. reviewing, thanks in advance. I opened PR112786 to get an ID for the issue. brgds, H-P ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-30 17:09 ` Hans-Peter Nilsson @ 2023-12-01 2:38 ` Hans-Peter Nilsson 2023-12-01 3:35 ` Hans-Peter Nilsson 2023-12-01 3:41 ` Hans-Peter Nilsson 2 siblings, 0 replies; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-12-01 2:38 UTC (permalink / raw) To: Hans-Peter Nilsson Cc: oliva, botcazou, rguenther, jeffreyalaw, ro, gcc-patches, mikestump > From: Hans-Peter Nilsson <hp@axis.com> > Date: Thu, 30 Nov 2023 18:09:10 +0100 > I intend to post two alternative patches to get this > resolved: > 1: Move the tests to gcc.target/i386/scev-[3-5].c > 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed > only on h8300-*-* and ia32. Correction: h8300-elf does not XPASS not because it's a ilp32 that fails, but because it's not an ilp32 and does not match the XFAIL selector, therefore it passes. IOW, minimizing the negations: h8300-elf is apparently an "i16lp32" and passes. No need for special-casing. TIL, TMRIF. brgds, H-P ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-30 17:09 ` Hans-Peter Nilsson 2023-12-01 2:38 ` Hans-Peter Nilsson @ 2023-12-01 3:35 ` Hans-Peter Nilsson 2023-12-01 7:07 ` Richard Biener 2023-12-01 3:41 ` Hans-Peter Nilsson 2 siblings, 1 reply; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-12-01 3:35 UTC (permalink / raw) To: oliva, gcc-patches; +Cc: botcazou, rguenther, jeffreyalaw, ro, mikestump > From: Hans-Peter Nilsson <hp@axis.com> > Date: Thu, 30 Nov 2023 18:09:10 +0100 Richard B.: > > > In the end we might need to move/duplicate the test to some > > > gcc.target/* dir and restrict it to a specific tuning. > > I intend to post two alternative patches to get this > resolved: > 1: Move the tests to gcc.target/i386/scev-[3-5].c Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c and -5.c [PR112786] This is the first alternative, perhaps the more appropriate one. Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32, h8300-elf and shle-linux; xpassing, skipped and passing as applicable and intended. Ok to commit? -- >8 -- PR testsuite/112786 * gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c, gcc.dg/tree-ssa/scev-5.c: Revert last change and move... * gcc.target/i386/scev-3.c, gcc.target/i386/scev-4.c: gcc.target/i386/scev-5.c: ...here. --- gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c | 3 +-- gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c | 3 +-- gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c (80%) rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c (81%) rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c (81%) diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.target/i386/scev-3.c similarity index 80% rename from gcc/testsuite/gcc.dg/tree-ssa/scev-3.c rename to gcc/testsuite/gcc.target/i386/scev-3.c index beea9aed9fe9..ac8c8d4519e3 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c +++ b/gcc/testsuite/gcc.target/i386/scev-3.c @@ -40,5 +40,4 @@ __BB(6): } -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c b/gcc/testsuite/gcc.target/i386/scev-4.c similarity index 81% rename from gcc/testsuite/gcc.dg/tree-ssa/scev-4.c rename to gcc/testsuite/gcc.target/i386/scev-4.c index a97f75f81f65..b0d594053019 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c +++ b/gcc/testsuite/gcc.target/i386/scev-4.c @@ -45,5 +45,4 @@ __BB(6): } -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.target/i386/scev-5.c similarity index 81% rename from gcc/testsuite/gcc.dg/tree-ssa/scev-5.c rename to gcc/testsuite/gcc.target/i386/scev-5.c index 08f4260403c4..c911a9298866 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c +++ b/gcc/testsuite/gcc.target/i386/scev-5.c @@ -40,5 +40,4 @@ __BB(6): } -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ -- 2.30.2 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-12-01 3:35 ` Hans-Peter Nilsson @ 2023-12-01 7:07 ` Richard Biener 2023-12-01 23:18 ` Hans-Peter Nilsson 0 siblings, 1 reply; 17+ messages in thread From: Richard Biener @ 2023-12-01 7:07 UTC (permalink / raw) To: Hans-Peter Nilsson Cc: oliva, gcc-patches, botcazou, jeffreyalaw, ro, mikestump On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > From: Hans-Peter Nilsson <hp@axis.com> > > Date: Thu, 30 Nov 2023 18:09:10 +0100 > > Richard B.: > > > > In the end we might need to move/duplicate the test to some > > > > gcc.target/* dir and restrict it to a specific tuning. > > > > I intend to post two alternative patches to get this > > resolved: > > 1: Move the tests to gcc.target/i386/scev-[3-5].c > > Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c and -5.c [PR112786] > > This is the first alternative, perhaps the more appropriate one. > > Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32, > h8300-elf and shle-linux; xpassing, skipped and passing as > applicable and intended. > > Ok to commit? Digging in history reveals the testcases were added by Jiangning Liu <jiangning.liu@arm.com>, not for any particular bugreport but "The problem is originally from a real benchmark, and the test case only tries to detect the GIMPLE level changes." I'm not sure we can infer the testcase should be moved to gcc.target/arm/ because of that, but it does seem plausible. I read from your messages that the testcases pass on arm*-*-*? Richard. > -- >8 -- > PR testsuite/112786 > * gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c, > gcc.dg/tree-ssa/scev-5.c: Revert last change and move... > * gcc.target/i386/scev-3.c, gcc.target/i386/scev-4.c: > gcc.target/i386/scev-5.c: ...here. > --- > gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c | 3 +-- > gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c | 3 +-- > gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c | 3 +-- > 3 files changed, 3 insertions(+), 6 deletions(-) > rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c (80%) > rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c (81%) > rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c (81%) > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.target/i386/scev-3.c > similarity index 80% > rename from gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > rename to gcc/testsuite/gcc.target/i386/scev-3.c > index beea9aed9fe9..ac8c8d4519e3 100644 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > +++ b/gcc/testsuite/gcc.target/i386/scev-3.c > @@ -40,5 +40,4 @@ __BB(6): > > } > > -/* Not all 32-bit systems fail this, but several do. */ > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ > +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c b/gcc/testsuite/gcc.target/i386/scev-4.c > similarity index 81% > rename from gcc/testsuite/gcc.dg/tree-ssa/scev-4.c > rename to gcc/testsuite/gcc.target/i386/scev-4.c > index a97f75f81f65..b0d594053019 100644 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c > +++ b/gcc/testsuite/gcc.target/i386/scev-4.c > @@ -45,5 +45,4 @@ __BB(6): > > } > > -/* Not all 32-bit systems fail this, but several do. */ > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ > +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.target/i386/scev-5.c > similarity index 81% > rename from gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > rename to gcc/testsuite/gcc.target/i386/scev-5.c > index 08f4260403c4..c911a9298866 100644 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > +++ b/gcc/testsuite/gcc.target/i386/scev-5.c > @@ -40,5 +40,4 @@ __BB(6): > > } > > -/* Not all 32-bit systems fail this, but several do. */ > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ > +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ > -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-12-01 7:07 ` Richard Biener @ 2023-12-01 23:18 ` Hans-Peter Nilsson 2023-12-04 11:58 ` Richard Biener 0 siblings, 1 reply; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-12-01 23:18 UTC (permalink / raw) To: Richard Biener; +Cc: oliva, gcc-patches, botcazou, jeffreyalaw, ro, mikestump > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > From: Richard Biener <rguenther@suse.de> > On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > > > From: Hans-Peter Nilsson <hp@axis.com> > > > Date: Thu, 30 Nov 2023 18:09:10 +0100 > > > > Richard B.: > > > > > In the end we might need to move/duplicate the test to some > > > > > gcc.target/* dir and restrict it to a specific tuning. > > > > > > I intend to post two alternative patches to get this > > > resolved: > > > 1: Move the tests to gcc.target/i386/scev-[3-5].c > > > > Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c and -5.c [PR112786] > > > > This is the first alternative, perhaps the more appropriate one. > > > > Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32, > > h8300-elf and shle-linux; xpassing, skipped and passing as > > applicable and intended. > > > > Ok to commit? > > Digging in history reveals the testcases were added by > Jiangning Liu <jiangning.liu@arm.com>, not for any > particular bugreport but "The problem is originally from a real benchmark, > and the test case only tries to detect the GIMPLE level changes." > > I'm not sure we can infer the testcase should be moved to > gcc.target/arm/ because of that, but it does seem plausible. It's been so long and so many changes since these tests were regression guards, that the original target has lost importance. Heck, it was even xfail lp64 at one time! According to my git dig, it's been adjusted for pass changes, including reordering and dump output changes. But you know that; you've been instrumental in many of those changes. :) I'd say gcc.target/arm/ is the one target that's *not* plausible, as according to Alex result differs between subtargets. > I read from your messages that the testcases pass on arm*-*-*? Yes: they pass (currently XPASS) on arm-eabi and arm-unknown-linux-gnueabi, default configurations. But, scev-3 and -5 fail with for example -mcpu=cortex-r5 brgds, H-P PS. I'm open to just reverting the patch. The s/ia32/ilp32/ is proven wrong. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-12-01 23:18 ` Hans-Peter Nilsson @ 2023-12-04 11:58 ` Richard Biener 2023-12-07 16:33 ` Hans-Peter Nilsson 0 siblings, 1 reply; 17+ messages in thread From: Richard Biener @ 2023-12-04 11:58 UTC (permalink / raw) To: Hans-Peter Nilsson Cc: oliva, gcc-patches, botcazou, jeffreyalaw, ro, mikestump On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > > From: Richard Biener <rguenther@suse.de> > > > On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > > > > > From: Hans-Peter Nilsson <hp@axis.com> > > > > Date: Thu, 30 Nov 2023 18:09:10 +0100 > > > > > > Richard B.: > > > > > > In the end we might need to move/duplicate the test to some > > > > > > gcc.target/* dir and restrict it to a specific tuning. > > > > > > > > I intend to post two alternative patches to get this > > > > resolved: > > > > 1: Move the tests to gcc.target/i386/scev-[3-5].c > > > > > > Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c and -5.c [PR112786] > > > > > > This is the first alternative, perhaps the more appropriate one. > > > > > > Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32, > > > h8300-elf and shle-linux; xpassing, skipped and passing as > > > applicable and intended. > > > > > > Ok to commit? > > > > Digging in history reveals the testcases were added by > > Jiangning Liu <jiangning.liu@arm.com>, not for any > > particular bugreport but "The problem is originally from a real benchmark, > > and the test case only tries to detect the GIMPLE level changes." > > > > I'm not sure we can infer the testcase should be moved to > > gcc.target/arm/ because of that, but it does seem plausible. > > It's been so long and so many changes since these tests were > regression guards, that the original target has lost > importance. Heck, it was even xfail lp64 at one time! > According to my git dig, it's been adjusted for pass > changes, including reordering and dump output changes. But > you know that; you've been instrumental in many of those > changes. :) > > I'd say gcc.target/arm/ is the one target that's *not* > plausible, as according to Alex result differs between > subtargets. > > > I read from your messages that the testcases pass on arm*-*-*? > > Yes: they pass (currently XPASS) on arm-eabi and > arm-unknown-linux-gnueabi, default configurations. But, > scev-3 and -5 fail with for example -mcpu=cortex-r5 I see. As said, the testcases test for "cost" things, so that we "regressed" might mean we really "regressed" here. Even the x86 -m32 result is questionable. Of course whether using a single IV makes sense for all archs is unknown. Btw, if we turn the testcases into ones that are (sub-)target specific then we want to again use C code as input. I think at this point we've lost track and I'm juggling between removing the testcases or moving them to a place they succeed (with some specific -mcpu=?) Richard. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-12-04 11:58 ` Richard Biener @ 2023-12-07 16:33 ` Hans-Peter Nilsson 2023-12-07 21:03 ` Jeff Law 2023-12-08 6:46 ` Richard Biener 0 siblings, 2 replies; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-12-07 16:33 UTC (permalink / raw) To: Richard Biener; +Cc: oliva, gcc-patches, botcazou, jeffreyalaw, ro, mikestump > Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET) > From: Richard Biener <rguenther@suse.de> > On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: > > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > > > From: Richard Biener <rguenther@suse.de> > > > I read from your messages that the testcases pass on arm*-*-*? > > Yes: they pass (currently XPASS) on arm-eabi and > > arm-unknown-linux-gnueabi, default configurations. But, > > scev-3 and -5 fail with for example -mcpu=cortex-r5 > > I see. As said, the testcases test for "cost" things, so that we > "regressed" might mean we really "regressed" here. Even the x86 -m32 > result is questionable. > > Of course whether using a single IV makes sense for all archs is > unknown. > > Btw, if we turn the testcases into ones that are (sub-)target > specific then we want to again use C code as input. > > I think at this point we've lost track and I'm juggling between > removing the testcases or moving them to a place they succeed > (with some specific -mcpu=?) > > Richard. So to not drop the ball(s) on this, here's a patch with your first alternative: remove them. Ok? -- >8 -- Subject: [PATCH] testsuite: Remove gcc.dg/tree-ssa/scev-3.c -4.c and 5.c These tests were recently xfailed on ilp32 targets though passing on almost all ilp32 targets (known exceptions: ia32 and some arm subtargets). They've been changed around too much to remain useful. PR testsuite/112786 * gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c, gcc.dg/tree-ssa/scev-5.c: Remove. --- gcc/testsuite/gcc.dg/tree-ssa/scev-3.c | 44 ----------------------- gcc/testsuite/gcc.dg/tree-ssa/scev-4.c | 49 -------------------------- gcc/testsuite/gcc.dg/tree-ssa/scev-5.c | 44 ----------------------- 3 files changed, 137 deletions(-) delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-3.c delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-4.c delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-5.c diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c deleted file mode 100644 index beea9aed9fe9..000000000000 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c +++ /dev/null @@ -1,44 +0,0 @@ -/* { dg-do compile } */ -/* { dg-options "-O2 -fgimple -fdump-tree-ivopts" } */ - -int *a_p; -int a[1000]; - -void __GIMPLE (ssa,startwith ("loop")) -f (int k) -{ - int i; - int * _1; - -__BB(2): - i_5 = k_4(D); - if (i_5 <= 999) - goto __BB4; - else - goto __BB3; - -__BB(3): - return; - -__BB(4): - goto __BB5; - -__BB(5): - i_12 = __PHI (__BB6: i_9, __BB4: i_5); - _1 = &a[i_12]; - a_p = _1; - __MEM <int[1000]> ((int *)&a)[i_12] = 100; - i_9 = i_5 + i_12; - if (i_9 <= 999) - goto __BB6; - else - goto __BB3; - -__BB(6): - ; - goto __BB5; - -} - -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c deleted file mode 100644 index a97f75f81f65..000000000000 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c +++ /dev/null @@ -1,49 +0,0 @@ -/* { dg-do compile } */ -/* { dg-options "-O2 -fgimple -fdump-tree-ivopts" } */ - -typedef struct { - int x; - int y; -} S; - -int *a_p; -S a[1000]; - -void __GIMPLE (ssa, startwith ("loop")) -f (int k) -{ - int i; - int * _1; - -__BB(2): - i_5 = k_4(D); - if (i_5 <= 999) - goto __BB4; - else - goto __BB3; - -__BB(3): - return; - -__BB(4): - goto __BB5; - -__BB(5): - i_12 = __PHI (__BB6: i_9, __BB4: i_5); - _1 = &a[i_12].y; - a_p = _1; - __MEM <S[1000]> ((int *)&a)[i_12].y = 100; - i_9 = i_5 + i_12; - if (i_9 <= 999) - goto __BB6; - else - goto __BB3; - -__BB(6): - ; - goto __BB5; - -} - -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c deleted file mode 100644 index 08f4260403c4..000000000000 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c +++ /dev/null @@ -1,44 +0,0 @@ -/* { dg-do compile } */ -/* { dg-options "-O2 -fgimple -fdump-tree-ivopts" } */ - -int *a_p; -int a[1000]; - -void __GIMPLE (ssa,startwith ("loop")) -f (int k) -{ - long long int i; - int * _1; - -__BB(2): - i_5 = (long long int) k_4(D); - if (i_5 <= 999ll) - goto __BB4; - else - goto __BB3; - -__BB(3): - return; - -__BB(4): - goto __BB5; - -__BB(5): - i_12 = __PHI (__BB6: i_9, __BB4: i_5); - _1 = &a[i_12]; - a_p = _1; - __MEM <int[1000]> ((int *)&a)[i_12] = 100; - i_9 = i_5 + i_12; - if (i_9 <= 999ll) - goto __BB6; - else - goto __BB3; - -__BB(6): - ; - goto __BB5; - -} - -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ -- 2.30.2 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-12-07 16:33 ` Hans-Peter Nilsson @ 2023-12-07 21:03 ` Jeff Law 2023-12-08 6:46 ` Richard Biener 1 sibling, 0 replies; 17+ messages in thread From: Jeff Law @ 2023-12-07 21:03 UTC (permalink / raw) To: Hans-Peter Nilsson, Richard Biener Cc: oliva, gcc-patches, botcazou, ro, mikestump On 12/7/23 09:33, Hans-Peter Nilsson wrote: >> Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET) >> From: Richard Biener <rguenther@suse.de> > >> On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: >>>> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) >>>> From: Richard Biener <rguenther@suse.de> >>>> I read from your messages that the testcases pass on arm*-*-*? >>> Yes: they pass (currently XPASS) on arm-eabi and >>> arm-unknown-linux-gnueabi, default configurations. But, >>> scev-3 and -5 fail with for example -mcpu=cortex-r5 >> >> I see. As said, the testcases test for "cost" things, so that we >> "regressed" might mean we really "regressed" here. Even the x86 -m32 >> result is questionable. >> >> Of course whether using a single IV makes sense for all archs is >> unknown. >> >> Btw, if we turn the testcases into ones that are (sub-)target >> specific then we want to again use C code as input. >> >> I think at this point we've lost track and I'm juggling between >> removing the testcases or moving them to a place they succeed >> (with some specific -mcpu=?) >> >> Richard. > > So to not drop the ball(s) on this, here's a patch with your > first alternative: remove them. > > Ok? OK, but give Richard until Monday PM to chime in if he wants to try and save them by putting them into a target specific directory. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-12-07 16:33 ` Hans-Peter Nilsson 2023-12-07 21:03 ` Jeff Law @ 2023-12-08 6:46 ` Richard Biener 1 sibling, 0 replies; 17+ messages in thread From: Richard Biener @ 2023-12-08 6:46 UTC (permalink / raw) To: Hans-Peter Nilsson Cc: oliva, gcc-patches, botcazou, jeffreyalaw, ro, mikestump On Thu, 7 Dec 2023, Hans-Peter Nilsson wrote: > > Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET) > > From: Richard Biener <rguenther@suse.de> > > > On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: > > > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > > > > From: Richard Biener <rguenther@suse.de> > > > > I read from your messages that the testcases pass on arm*-*-*? > > > Yes: they pass (currently XPASS) on arm-eabi and > > > arm-unknown-linux-gnueabi, default configurations. But, > > > scev-3 and -5 fail with for example -mcpu=cortex-r5 > > > > I see. As said, the testcases test for "cost" things, so that we > > "regressed" might mean we really "regressed" here. Even the x86 -m32 > > result is questionable. > > > > Of course whether using a single IV makes sense for all archs is > > unknown. > > > > Btw, if we turn the testcases into ones that are (sub-)target > > specific then we want to again use C code as input. > > > > I think at this point we've lost track and I'm juggling between > > removing the testcases or moving them to a place they succeed > > (with some specific -mcpu=?) > > > > Richard. > > So to not drop the ball(s) on this, here's a patch with your > first alternative: remove them. > > Ok? OK. Thanks, Richard. > -- >8 -- > Subject: [PATCH] testsuite: Remove gcc.dg/tree-ssa/scev-3.c -4.c and 5.c > > These tests were recently xfailed on ilp32 targets though > passing on almost all ilp32 targets (known exceptions: ia32 > and some arm subtargets). They've been changed around too > much to remain useful. > > PR testsuite/112786 > * gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c, > gcc.dg/tree-ssa/scev-5.c: Remove. > --- > gcc/testsuite/gcc.dg/tree-ssa/scev-3.c | 44 ----------------------- > gcc/testsuite/gcc.dg/tree-ssa/scev-4.c | 49 -------------------------- > gcc/testsuite/gcc.dg/tree-ssa/scev-5.c | 44 ----------------------- > 3 files changed, 137 deletions(-) > delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-4.c > delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > deleted file mode 100644 > index beea9aed9fe9..000000000000 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > +++ /dev/null > @@ -1,44 +0,0 @@ > -/* { dg-do compile } */ > -/* { dg-options "-O2 -fgimple -fdump-tree-ivopts" } */ > - > -int *a_p; > -int a[1000]; > - > -void __GIMPLE (ssa,startwith ("loop")) > -f (int k) > -{ > - int i; > - int * _1; > - > -__BB(2): > - i_5 = k_4(D); > - if (i_5 <= 999) > - goto __BB4; > - else > - goto __BB3; > - > -__BB(3): > - return; > - > -__BB(4): > - goto __BB5; > - > -__BB(5): > - i_12 = __PHI (__BB6: i_9, __BB4: i_5); > - _1 = &a[i_12]; > - a_p = _1; > - __MEM <int[1000]> ((int *)&a)[i_12] = 100; > - i_9 = i_5 + i_12; > - if (i_9 <= 999) > - goto __BB6; > - else > - goto __BB3; > - > -__BB(6): > - ; > - goto __BB5; > - > -} > - > -/* Not all 32-bit systems fail this, but several do. */ > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c > deleted file mode 100644 > index a97f75f81f65..000000000000 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c > +++ /dev/null > @@ -1,49 +0,0 @@ > -/* { dg-do compile } */ > -/* { dg-options "-O2 -fgimple -fdump-tree-ivopts" } */ > - > -typedef struct { > - int x; > - int y; > -} S; > - > -int *a_p; > -S a[1000]; > - > -void __GIMPLE (ssa, startwith ("loop")) > -f (int k) > -{ > - int i; > - int * _1; > - > -__BB(2): > - i_5 = k_4(D); > - if (i_5 <= 999) > - goto __BB4; > - else > - goto __BB3; > - > -__BB(3): > - return; > - > -__BB(4): > - goto __BB5; > - > -__BB(5): > - i_12 = __PHI (__BB6: i_9, __BB4: i_5); > - _1 = &a[i_12].y; > - a_p = _1; > - __MEM <S[1000]> ((int *)&a)[i_12].y = 100; > - i_9 = i_5 + i_12; > - if (i_9 <= 999) > - goto __BB6; > - else > - goto __BB3; > - > -__BB(6): > - ; > - goto __BB5; > - > -} > - > -/* Not all 32-bit systems fail this, but several do. */ > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > deleted file mode 100644 > index 08f4260403c4..000000000000 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > +++ /dev/null > @@ -1,44 +0,0 @@ > -/* { dg-do compile } */ > -/* { dg-options "-O2 -fgimple -fdump-tree-ivopts" } */ > - > -int *a_p; > -int a[1000]; > - > -void __GIMPLE (ssa,startwith ("loop")) > -f (int k) > -{ > - long long int i; > - int * _1; > - > -__BB(2): > - i_5 = (long long int) k_4(D); > - if (i_5 <= 999ll) > - goto __BB4; > - else > - goto __BB3; > - > -__BB(3): > - return; > - > -__BB(4): > - goto __BB5; > - > -__BB(5): > - i_12 = __PHI (__BB6: i_9, __BB4: i_5); > - _1 = &a[i_12]; > - a_p = _1; > - __MEM <int[1000]> ((int *)&a)[i_12] = 100; > - i_9 = i_5 + i_12; > - if (i_9 <= 999ll) > - goto __BB6; > - else > - goto __BB3; > - > -__BB(6): > - ; > - goto __BB5; > - > -} > - > -/* Not all 32-bit systems fail this, but several do. */ > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ > -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] testsuite: scev: expect fail on ilp32 2023-11-30 17:09 ` Hans-Peter Nilsson 2023-12-01 2:38 ` Hans-Peter Nilsson 2023-12-01 3:35 ` Hans-Peter Nilsson @ 2023-12-01 3:41 ` Hans-Peter Nilsson 2 siblings, 0 replies; 17+ messages in thread From: Hans-Peter Nilsson @ 2023-12-01 3:41 UTC (permalink / raw) To: oliva, gcc-patches; +Cc: botcazou, rguenther, jeffreyalaw, ro, mikestump > From: Hans-Peter Nilsson <hp@axis.com> > Date: Thu, 30 Nov 2023 18:09:10 +0100 > I intend to post two alternative patches to get this > resolved: > 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed > only on h8300-*-* and ia32. (Except as mentioned, the XPASS issue does not apply to h8300; it's "i16lp32". It remains in the set of targets that were tested though.) Subject: [PATCH 2/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c and -5.c [PR112786] This is the second alternative, slightly more trivial than the first. Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32, h8300-elf and shle-linux; xpassing, skipped and passing as applicable and intended. Ok to commit? -- >8 -- Results differ between ARM sub-targets, thus better to skip these tests. They are known to fail only for ia32-elf. PR testsuite/112786 * gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c, gcc.dg/tree-ssa/scev-5.c: Revert last change. Instead, skip dump match for arm*. --- gcc/testsuite/gcc.dg/tree-ssa/scev-3.c | 3 +-- gcc/testsuite/gcc.dg/tree-ssa/scev-4.c | 3 +-- gcc/testsuite/gcc.dg/tree-ssa/scev-5.c | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c index beea9aed9fe9..6e9733504014 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c @@ -40,5 +40,4 @@ __BB(6): } -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { target { ! arm*-*-* } xfail ia32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c index a97f75f81f65..a0cf171f01be 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c @@ -45,5 +45,4 @@ __BB(6): } -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { target { ! arm*-*-* } xfail ia32 } } } */ diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c index 08f4260403c4..0bd743cc6be6 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c @@ -40,5 +40,4 @@ __BB(6): } -/* Not all 32-bit systems fail this, but several do. */ -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ilp32 } } } */ +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { target { ! arm*-*-* } xfail ia32 } } } */ -- 2.30.2 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-12-08 6:47 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-11-19 7:30 [PATCH] testsuite: scev: expect fail on ilp32 Alexandre Oliva 2023-11-19 15:12 ` Jeff Law 2023-11-20 7:35 ` Richard Biener 2023-11-28 15:13 ` Rainer Orth 2023-11-29 18:00 ` Hans-Peter Nilsson 2023-11-30 4:41 ` Alexandre Oliva 2023-11-30 8:32 ` Richard Biener 2023-11-30 17:09 ` Hans-Peter Nilsson 2023-12-01 2:38 ` Hans-Peter Nilsson 2023-12-01 3:35 ` Hans-Peter Nilsson 2023-12-01 7:07 ` Richard Biener 2023-12-01 23:18 ` Hans-Peter Nilsson 2023-12-04 11:58 ` Richard Biener 2023-12-07 16:33 ` Hans-Peter Nilsson 2023-12-07 21:03 ` Jeff Law 2023-12-08 6:46 ` Richard Biener 2023-12-01 3:41 ` Hans-Peter Nilsson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).