> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> From: Richard Biener <rguent...@suse.de>

> On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:
> 
> > > From: Hans-Peter Nilsson <h...@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....@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.

Reply via email to