> From: Alexandre Oliva <ol...@adacore.com> > Date: Thu, 30 Nov 2023 01:41:55 -0300
> On Nov 29, 2023, Hans-Peter Nilsson <h...@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
