[committed] testsuite: Add testcases from PR108292 and PR108308

Message ID Y7fwNTmas50x4CUm@tucnak
State Accepted
Headers
Series [committed] testsuite: Add testcases from PR108292 and PR108308 |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Jakub Jelinek Jan. 6, 2023, 9:56 a.m. UTC
  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

NightStrike Jan. 11, 2023, 8:58 a.m. UTC | #1
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?
  
Jakub Jelinek Jan. 11, 2023, 9:06 a.m. UTC | #2
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
  
NightStrike Jan. 11, 2023, 9:27 a.m. UTC | #3
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!)
  
Jakub Jelinek Jan. 11, 2023, 9:43 a.m. UTC | #4
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
  
NightStrike Jan. 11, 2023, 10:10 a.m. UTC | #5
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 :)
  
Jakub Jelinek Jan. 11, 2023, 12:14 p.m. UTC | #6
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
  
NightStrike Jan. 11, 2023, 12:22 p.m. UTC | #7
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?
  

Patch

--- gcc/testsuite/gcc.c-torture/execute/pr108292.c.jj	2023-01-06 10:40:20.742991257 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr108292.c	2023-01-06 10:41:56.589597398 +0100
@@ -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;
+}
--- gcc/testsuite/gcc.target/i386/pr108292.c.jj	2023-01-06 10:50:12.382388648 +0100
+++ gcc/testsuite/gcc.target/i386/pr108292.c	2023-01-06 10:50:05.704485693 +0100
@@ -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;
+}
--- 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 } } } */
+/* { 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;
+}