Re: [PATCH] testsuite: scev: expect fail on ilp32
On Thu, 7 Dec 2023, Hans-Peter Nilsson wrote:
> > Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET)
> > From: Richard Biener
>
> > On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote:
> > > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> > > > From: Richard Biener
> > > > 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..
> --- 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 = [i_12];
> - a_p = _1;
> - __MEM ((int *))[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 "" 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..
> --- 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 = [i_12].y;
> - a_p = _1;
> - __MEM ((int *))[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 "" 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..
> --- 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 = [i_12];
> - a_p = _1;
> - __MEM ((int *))[i_12] = 100;
> - i_9 = i_5 +
Re: [PATCH] testsuite: scev: expect fail on ilp32
On 12/7/23 09:33, Hans-Peter Nilsson wrote: Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET) From: Richard Biener On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) From: Richard Biener 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
Re: [PATCH] testsuite: scev: expect fail on ilp32
> Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET)
> From: Richard Biener
> On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote:
> > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> > > From: Richard Biener
> > > 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..
--- 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 = [i_12];
- a_p = _1;
- __MEM ((int *))[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 "" 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..
--- 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 = [i_12].y;
- a_p = _1;
- __MEM ((int *))[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 "" 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..
--- 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 = [i_12];
- a_p = _1;
- __MEM ((int *))[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 "" 1 "ivopts" { xfail ilp32 } } } */
--
2.30.2
Re: [PATCH] testsuite: scev: expect fail on ilp32
On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > > From: Richard Biener > > > On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > > > > > From: Hans-Peter Nilsson > > > > 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 , 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.
Re: [PATCH] testsuite: scev: expect fail on ilp32
> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > From: Richard Biener > On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > > > From: Hans-Peter Nilsson > > > 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 , 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.
Re: [PATCH] testsuite: scev: expect fail on ilp32
On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:
> > From: Hans-Peter Nilsson
> > 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 , 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 "" 1 "ivopts" { xfail ilp32 } } } */
> +/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ilp32 } } } */
> +/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ilp32 } } } */
> +/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH] testsuite: scev: expect fail on ilp32
> From: Hans-Peter Nilsson
> 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 "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { target { ! arm*-*-* }
xfail ia32 } } } */
--
2.30.2
Re: [PATCH] testsuite: scev: expect fail on ilp32
> From: Hans-Peter Nilsson
> 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 "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
--
2.30.2
Re: [PATCH] testsuite: scev: expect fail on ilp32
> From: Hans-Peter Nilsson > 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
Re: [PATCH] testsuite: scev: expect fail on ilp32
> From: Alexandre Oliva > Date: Thu, 30 Nov 2023 01:41:55 -0300 > On Nov 29, 2023, Hans-Peter Nilsson wrote: > > >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "" 1 > >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1 > >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "" 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
Re: [PATCH] testsuite: scev: expect fail on ilp32
On Thu, 30 Nov 2023, Alexandre Oliva wrote: > On Nov 29, 2023, Hans-Peter Nilsson wrote: > > >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "" 1 > >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1 > >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "" 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.
Re: [PATCH] testsuite: scev: expect fail on ilp32
On Nov 29, 2023, Hans-Peter Nilsson wrote: >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "" 1 >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1 >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "" 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 hackerhttps://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
Re: [PATCH] testsuite: scev: expect fail on ilp32
> From: Rainer Orth
> Date: Tue, 28 Nov 2023 16:13:35 +0100
> Richard Biener 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 "" 1
> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1
> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "" 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
Re: [PATCH] testsuite: scev: expect fail on ilp32
Richard Biener 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 "" 1 XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1 XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "" 1 Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] testsuite: scev: expect fail on ilp32
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.
Re: [PATCH] testsuite: scev: expect fail on ilp32
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
[PATCH] testsuite: scev: expect fail on ilp32
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 "" 1 "ivopts" { xfail ia32 } } } */
+/* Not all 32-bit systems fail this, but several do. */
+/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" } } */
+/* Not all 32-bit systems fail this, but several do. */
+/* { dg-final { scan-tree-dump-times "" 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 "" 1 "ivopts" { xfail ia32 } } } */
+/* Not all 32-bit systems fail this, but several do. */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
--
Alexandre Oliva, happy hackerhttps://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
