[committed] testsuite: Add testcases from PR108292 and PR108308
Checks
Commit Message
Hi!
These PRs were for now fixed by reversion of the r13-4977
patch, but so that the problems don't reappear during stage 1,
I'm adding testcase coverage from those PRs.
Tested on x86_64-linux -m32/-m64 before r13-5038 (where all tests
FAIL) and after it (where they PASS), committed to trunk as obvious.
2023-01-06 Jakub Jelinek <jakub@redhat.com>
PR target/108292
PR target/108308
* gcc.c-torture/execute/pr108292.c: New test.
* gcc.target/i386/pr108292.c: New test.
* gcc.dg/pr108308.c: New test.
Jakub
Comments
On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
> --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
> +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> @@ -0,0 +1,39 @@
> +/* PR target/108308 */
> +/* { dg-do run { target { ilp32 || lp64 } } } */
This test passes on Windows, and I don't see anything in the test that
jumps out at me as being affected by storing pointers in longs. Is
there something I'm missing about why this would be disabled on LLP64?
On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> > --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
> > +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> > @@ -0,0 +1,39 @@
> > +/* PR target/108308 */
> > +/* { dg-do run { target { ilp32 || lp64 } } } */
>
> This test passes on Windows, and I don't see anything in the test that
> jumps out at me as being affected by storing pointers in longs. Is
> there something I'm missing about why this would be disabled on LLP64?
Maybe the test just needs int32, it didn't look important enough to me.
ilp32 || lp64 covers most of important targets.
Jakub
On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> > > --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
> > > +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> > > @@ -0,0 +1,39 @@
> > > +/* PR target/108308 */
> > > +/* { dg-do run { target { ilp32 || lp64 } } } */
> >
> > This test passes on Windows, and I don't see anything in the test that
> > jumps out at me as being affected by storing pointers in longs. Is
> > there something I'm missing about why this would be disabled on LLP64?
>
> Maybe the test just needs int32, it didn't look important enough to me.
> ilp32 || lp64 covers most of important targets.
Could you change to int32plus, then?
-/* { dg-do run { target { ilp32 || lp64 } } } */
+/* { dg-do run { target { int32plus } } } */
Windows is still a secondary platform, so it'd be nice to keep as many
tests working (and supported) as possible. I don't know what
qualifies as "important targets", but this is an easy win (pun
intended!)
On Wed, Jan 11, 2023 at 04:27:11AM -0500, NightStrike wrote:
> On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek <jakub@redhat.com> wrote:
> >
> > On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > > On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> > > <gcc-patches@gcc.gnu.org> wrote:
> > > > --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
> > > > +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> > > > @@ -0,0 +1,39 @@
> > > > +/* PR target/108308 */
> > > > +/* { dg-do run { target { ilp32 || lp64 } } } */
> > >
> > > This test passes on Windows, and I don't see anything in the test that
> > > jumps out at me as being affected by storing pointers in longs. Is
> > > there something I'm missing about why this would be disabled on LLP64?
> >
> > Maybe the test just needs int32, it didn't look important enough to me.
> > ilp32 || lp64 covers most of important targets.
>
> Could you change to int32plus, then?
I think int32plus would be wrong, the testcase has some overlarge constant
and I doubt it would work correctly on the hypothetical target with 64-bit
ints where the overlarge constant would fit into int.
Jakub
On Wed, Jan 11, 2023 at 4:43 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Wed, Jan 11, 2023 at 04:27:11AM -0500, NightStrike wrote:
> > On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek <jakub@redhat.com> wrote:
> > >
> > > On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > > > On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> > > > <gcc-patches@gcc.gnu.org> wrote:
> > > > > --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
> > > > > +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> > > > > @@ -0,0 +1,39 @@
> > > > > +/* PR target/108308 */
> > > > > +/* { dg-do run { target { ilp32 || lp64 } } } */
> > > >
> > > > This test passes on Windows, and I don't see anything in the test that
> > > > jumps out at me as being affected by storing pointers in longs. Is
> > > > there something I'm missing about why this would be disabled on LLP64?
> > >
> > > Maybe the test just needs int32, it didn't look important enough to me.
> > > ilp32 || lp64 covers most of important targets.
> >
> > Could you change to int32plus, then?
>
> I think int32plus would be wrong, the testcase has some overlarge constant
> and I doubt it would work correctly on the hypothetical target with 64-bit
> ints where the overlarge constant would fit into int.
Ok, then:
/* { dg-do run { target { { ilp32 || lp64 } || llp64 } } } */
or even:
/* { dg-do run { target { ! int16 } } } */
Though I'd point out that in your original message, you only cared
about the "important targets". I don't think nonexistent ones where
sizeof(int) == 8 qualifies :)
On Wed, Jan 11, 2023 at 05:10:50AM -0500, NightStrike wrote:
> Ok, then:
>
> /* { dg-do run { target { { ilp32 || lp64 } || llp64 } } } */
>
> or even:
>
> /* { dg-do run { target { ! int16 } } } */
>
> Though I'd point out that in your original message, you only cared
> about the "important targets". I don't think nonexistent ones where
> sizeof(int) == 8 qualifies :)
I've committed following after regtesting it on x86_64-linux and i686-linux:
2023-01-11 Jakub Jelinek <jakub@redhat.com>
PR target/108308
* gcc.dg/pr108308.c: Use int32 target rather than { ilp32 || lp64 }.
--- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:52:24.982461493 +0100
+++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-11 13:04:51.036789536 +0100
@@ -1,5 +1,5 @@
/* PR target/108308 */
-/* { dg-do run { target { ilp32 || lp64 } } } */
+/* { dg-do run { target int32 } } */
/* { dg-options "-Os -fno-tree-ccp" } */
int a = 1, *d = &a, f = 2766708631, h;
Jakub
On Wed, Jan 11, 2023 at 7:14 AM Jakub Jelinek <jakub@redhat.com> wrote:
> I've committed following after regtesting it on x86_64-linux and i686-linux:
...
> +/* { dg-do run { target int32 } } */
Ah, I didn't realize you meant literally int32. I didn't see that as
a choice here:
https://gcc.gnu.org/onlinedocs/gccint/Effective-Target-Keywords.html
Is that a case of missing documentation?
@@ -0,0 +1,18 @@
+/* PR target/108292 */
+
+typedef unsigned V __attribute__((__vector_size__ (64)));
+
+V x;
+
+int
+main ()
+{
+ if (sizeof (unsigned) * __CHAR_BIT__ != 32)
+ return 0;
+ __builtin_sub_overflow (0, 6, &x[5]);
+ x >>= ((V){} != x) & 31;
+ for (unsigned i = 0; i < 16; i++)
+ if (x[i] != (i == 5))
+ __builtin_abort ();
+ return 0;
+}
@@ -0,0 +1,15 @@
+/* PR target/108292 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -march=alderlake" } */
+
+extern void foo (float *);
+
+extern int x;
+
+int
+bar (void)
+{
+ float y;
+ foo (&y);
+ return y > x ? 1 : 2;
+}
@@ -0,0 +1,39 @@
+/* PR target/108308 */
+/* { dg-do run { target { ilp32 || lp64 } } } */
+/* { dg-options "-Os -fno-tree-ccp" } */
+
+int a = 1, *d = &a, f = 2766708631, h;
+unsigned b = -1, c, e, g;
+
+static void
+foo (int j)
+{
+ if (a)
+ {
+ c = ~c;
+ while (e)
+ j = 0;
+ goto k;
+ }
+l:
+ h = 1;
+k:
+ *d = (!j) | 80;
+ int m = ~(~(-1 / b) | (a ^ 1)), n = ~(~g / (11 >> m)), o = -1 / n;
+ if (f)
+ {
+ b = 9518150474215344 ^ ~f;
+ f = 0;
+ if (c)
+ goto l;
+ if (o)
+ goto k;
+ }
+}
+
+int
+main ()
+{
+ foo (1);
+ return 0;
+}