Re: [PATCH] libstdc++ testsuite: Increase lwg3464.cc timeout factors to 20

[Jonathan Wakely via Gcc-patches]

On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> These tests have always been failing for my cris-elf
> autotester running a simulator; they take about 20 minutes
> each, compared to the timeout of 720 seconds, doubled
> because they timed out in another simulator setup.
>
> They are the *only* libstdc++ tests that timeout for my
> setup so I thought this'd be best fixed in the testsuite
> rather than a local timeout setting (in e.g. the baseboard
> file).  And, better make it an increase that counts.  Or,
> maybe they're actually needlessly excessive?


They are testing behaviour when a counter overflows, so they have to read
that many bytes. Making them do less work would not test that condition.

But there is nothing target-specific in that code, so it should be fine to
disable them for simulators. They're already disabled for LP64 because
overflowing the 64-bit counter would take forever.

I think that would be better than letting them potentially run for 40
minutes even on real hardware.

Re: [EXTERNAL] [PATCH] testsuite: Fix up tree-ssa/pr103514.c testcase [PR103514]

[Navid Rahimi via Gcc-patches]

Thanks Jakob for the correction. Sadly, I didn’t have any access to any non x86 
architecture. But x86 was fully tested and there was no regression.

In my spare time I will look at implementation of this for short-circuit 
targets.

Best wishes,
Navid.

From: Jakub Jelinek 
Sent: Saturday, January 29, 2022 8:46:09 AM
To: Richard Biener ; Jeff Law 
Cc: Navid Rahimi ; gcc-patches@gcc.gnu.org 

Subject: [EXTERNAL] [PATCH] testsuite: Fix up tree-ssa/pr103514.c testcase 
[PR103514]

[You don't often get email from ja...@redhat.com. Learn why this is important 
at http://aka.ms/LearnAboutSenderIdentification.]

On Fri, Jan 28, 2022 at 03:14:16PM -0700, Jeff Law via Gcc-patches wrote:
> > This patch will add the missed pattern described in bug 103514 [1] to the 
> > match.pd. [1] includes proof of correctness for the patch too.
> >
> > PR tree-optimization/103514
> > * match.pd (a & b) ^ (a == b) -> !(a | b): New optimization.
> > * match.pd (a & b) == (a ^ b) -> !(a | b): New optimization.
> > * gcc.dg/tree-ssa/pr103514.c: Testcase for this optimization.
> >
> > 1) 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D103514&data=04%7C01%7Cnavidrahimi%40microsoft.com%7C712766ef9fc24c7ffeda08d9e346e086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790716153978385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CGslhJuy%2BTSrPpYbALD9pBh9945Hl6lINeHKmTEWqK0%3D&reserved=0
> Note the bug was filed an fixed during stage3, review just didn't happen in
> a reasonable timeframe.
>
> I'm going to ACK this for the trunk and go ahead and commit it for you.

The testcase FAILs on short-circuit targets like powerpc64le-linux.
While the first 2 functions are identical, the last two look like:
   :
  if (a_5(D) != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  if (b_6(D) != 0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.1_4 = PHI <1(3), 0(4)>
  _1 = a_5(D) == b_6(D);
  _2 = (int) _1;
  _3 = _2 ^ iftmp.1_4;
  _9 = _2 != iftmp.1_4;
  return _9;
instead of the expected:
   :
  _3 = a_8(D) & b_9(D);
  _4 = (int) _3;
  _5 = a_8(D) == b_9(D);
  _6 = (int) _5;
  _1 = a_8(D) | b_9(D);
  _2 = ~_1;
  _7 = (int) _2;
  _10 = ~_1;
  return _10;
so no wonder it doesn't match.  E.g. x86_64-linux will also use jumps
if it isn't just a && b but a && b && c && d (will do
a & b and c & d tests and jump based on those.

As it is too late to implement this optimization even for the short
circuiting targets this late (not even sure which pass would be best),
this patch just forces non-short-circuiting for the test.

Tested on x86_64-linux -m32/-m64 and powerpc64le-linux, ok for trunk?

2022-01-29  Jakub Jelinek  

PR tree-optimization/103514
* gcc.dg/tree-ssa/pr103514.c: Add
--param logical-op-non-short-circuit=1 to dg-options.

--- gcc/testsuite/gcc.dg/tree-ssa/pr103514.c.jj 2022-01-29 11:11:39.338627697 
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr103514.c2022-01-29 17:37:18.255237211 
+0100
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O -fdump-tree-optimized" } */
+/* { dg-options "-O --param logical-op-non-short-circuit=1 
-fdump-tree-optimized" } */
 #include 

 bool
@@ -30,4 +30,4 @@ h (bool a, bool b)
 /* Make sure we have removed "==" and "^" and "&". */
 /* { dg-final { scan-tree-dump-not "&" "optimized"} } */
 /* { dg-final { scan-tree-dump-not "\\^"  "optimized"} } */
-/* { dg-final { scan-tree-dump-not "==" "optimized"} } */
\ No newline at end of file
+/* { dg-final { scan-tree-dump-not "==" "optimized"} } */


Jakub

[PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

[Hans-Peter Nilsson via Gcc-patches]

(I had to add separation between your reply and mine in the
quoted parts; you may be aware.)

> From: Jonathan Wakely 
> Date: Sun, 30 Jan 2022 09:32:08 +0100
> On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, 
> mailto:libstdc%2b...@gcc.gnu.org>> wrote:
> > These tests have always been failing for my cris-elf
> > autotester running a simulator; they take about 20 minutes
> > each, compared to the timeout of 720 seconds, doubled
> > because they timed out in another simulator setup.
> >
> > They are the *only* libstdc++ tests that timeout for my
> > setup so I thought this'd be best fixed in the testsuite
> > rather than a local timeout setting (in e.g. the baseboard
> > file).  And, better make it an increase that counts.  Or,
> > maybe they're actually needlessly excessive?
> 
> They are testing behaviour when a counter overflows, so
> they have to read that many bytes. Making them do less
> work would not test that condition.
> 
> But there is nothing target-specific in that code, so it
> should be fine to disable them for simulators. They're
> already disabled for LP64 because overflowing the 64-bit
> counter would take forever.
> 
> I think that would be better than letting them potentially
> run for 40 minutes even on real hardware.

Ok.  Then this becomes obvious (except from the dejagnu
syntax, but that has an obvious progress path).  Also tested
that it still doesn't run nor gets some dejagnu error on
native x86_64-linux-gnu.

Committed.

8<->8
These tests have always been failing for my autotester running a
cris-elf simulator; when unrestrained they take about 20 minutes each,
compared to the (doubled) timeout of 720 seconds, of a total 2h40min
for the whole of the libstdc++-v3 testsuite.  The tests cover counter
overflow and are already disabled for LP64 targets.

* testsuite/27_io/basic_istream/get/char/lwg3464.cc: Don't run on
simulator targets.
* testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc: Likewise.
---
 libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc  | 2 +-
 .../testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
index f426ff7dd867..5d4de3d6cb54 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do run { target { ! lp64 } } }
+// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
 // { dg-timeout-factor 2 }
 
 #include 
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
index 4be6beb2310f..e2349df8c7d6 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do run { target { ! lp64 } } }
+// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
 // { dg-timeout-factor 2 }
 
 #include 
-- 
2.30.2

Re: [PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

[Jonathan Wakely via Gcc-patches]

On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson  wrote:
>
> (I had to add separation between your reply and mine in the
> quoted parts; you may be aware.)
>
> > From: Jonathan Wakely 
> > Date: Sun, 30 Jan 2022 09:32:08 +0100
> > On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, 
> > mailto:libstdc%2b...@gcc.gnu.org>> wrote:
> > > These tests have always been failing for my cris-elf
> > > autotester running a simulator; they take about 20 minutes
> > > each, compared to the timeout of 720 seconds, doubled
> > > because they timed out in another simulator setup.
> > >
> > > They are the *only* libstdc++ tests that timeout for my
> > > setup so I thought this'd be best fixed in the testsuite
> > > rather than a local timeout setting (in e.g. the baseboard
> > > file).  And, better make it an increase that counts.  Or,
> > > maybe they're actually needlessly excessive?
> >
> > They are testing behaviour when a counter overflows, so
> > they have to read that many bytes. Making them do less
> > work would not test that condition.
> >
> > But there is nothing target-specific in that code, so it
> > should be fine to disable them for simulators. They're
> > already disabled for LP64 because overflowing the 64-bit
> > counter would take forever.
> >
> > I think that would be better than letting them potentially
> > run for 40 minutes even on real hardware.
>
> Ok.  Then this becomes obvious (except from the dejagnu
> syntax, but that has an obvious progress path).  Also tested
> that it still doesn't run nor gets some dejagnu error on
> native x86_64-linux-gnu.
>
> Committed.

Thanks!


>
> 8<->8
> These tests have always been failing for my autotester running a
> cris-elf simulator; when unrestrained they take about 20 minutes each,
> compared to the (doubled) timeout of 720 seconds, of a total 2h40min
> for the whole of the libstdc++-v3 testsuite.  The tests cover counter
> overflow and are already disabled for LP64 targets.
>
> * testsuite/27_io/basic_istream/get/char/lwg3464.cc: Don't run on
> simulator targets.
> * testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc: Likewise.
> ---
>  libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc  | 2 +-
>  .../testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc 
> b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
> index f426ff7dd867..5d4de3d6cb54 100644
> --- a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
> +++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
> @@ -15,7 +15,7 @@
>  // with this library; see the file COPYING3.  If not see
>  // .
>
> -// { dg-do run { target { ! lp64 } } }
> +// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
>  // { dg-timeout-factor 2 }
>
>  #include 
> diff --git 
> a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc 
> b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
> index 4be6beb2310f..e2349df8c7d6 100644
> --- a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
> +++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
> @@ -15,7 +15,7 @@
>  // with this library; see the file COPYING3.  If not see
>  // .
>
> -// { dg-do run { target { ! lp64 } } }
> +// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
>  // { dg-timeout-factor 2 }
>
>  #include 
> --
> 2.30.2
>
>

Re: [PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

[Hans-Peter Nilsson via Gcc-patches]

> From: Jonathan Wakely 
> Date: Sun, 30 Jan 2022 18:06:28 +0100
> On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson  wrote:
> > > From: Jonathan Wakely 
> > > But there is nothing target-specific in that code, so it
> > > should be fine to disable them for simulators. They're
> > > already disabled for LP64 because overflowing the 64-bit
> > > counter would take forever.
> > >
> > > I think that would be better than letting them potentially
> > > run for 40 minutes even on real hardware.
> >
> > Ok.  Then this becomes obvious (except from the dejagnu
> > syntax, but that has an obvious progress path).  Also tested
> > that it still doesn't run nor gets some dejagnu error on
> > native x86_64-linux-gnu.
> >
> > Committed.
> 
> Thanks!

No reason, but thank *you* for the review and for the
biggest time win in test-cycle ever.  No, I didn't look, but
7% (720s*2)/5.5h - the total time; surely is unbeatable.

brgds, H-P

[PATCH] fold-const: do not fold 'inf/inf' with -ftrapping-math [PR95115]

[Xi Ruoyao via Gcc-patches]

'inf/inf' should raise an invalid operation exception at runtime.  So it
should not be folded during compilation unless -fno-trapping-math is
used.

gcc/
PR middle-end/95115
* fold-const.cc (const_binop): Do not fold "inf/inf".

gcc/testsuite
* gcc.dg/pr95115.c: New test.
---
 gcc/fold-const.cc  |  8 
 gcc/testsuite/gcc.dg/pr95115.c | 25 +
 2 files changed, 33 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr95115.c

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index fd9c6352d4f..0e99d5a2e3d 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -1283,6 +1283,14 @@ const_binop (enum tree_code code, tree arg1, tree arg2)
  && (flag_trapping_math || ! MODE_HAS_INFINITIES (mode)))
return NULL_TREE;
 
+  /* Don't perform "inf/inf", because it would raise an invalid
+operation exception (IEEE 754 section 7.2 clause d).  */
+  if (code == RDIV_EXPR
+ && flag_trapping_math
+ && REAL_VALUE_ISINF (d1)
+ && REAL_VALUE_ISINF (d2))
+   return NULL_TREE;
+
   /* If either operand is a NaN, just return it.  Otherwise, set up
 for floating-point trap; we return an overflow.  */
   if (REAL_VALUE_ISNAN (d1))
diff --git a/gcc/testsuite/gcc.dg/pr95115.c b/gcc/testsuite/gcc.dg/pr95115.c
new file mode 100644
index 000..46a95dfb698
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr95115.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -ftrapping-math" } */
+/* { dg-add-options ieee } */
+/* { dg-require-effective-target fenv_exceptions } */
+
+#include 
+#include 
+
+double
+x (void)
+{
+  double d = __builtin_inf ();
+  return d / d;
+}
+
+int
+main (void)
+{
+  double r = x ();
+  if (!__builtin_isnan (r))
+   abort ();
+  if (!fetestexcept (FE_INVALID))
+   abort ();
+  exit (0);
+}
-- 
2.35.1

[PATCH] libgccjit: Add support for setting the alignment [PR104293]

[Antoni Boucher via Gcc-patches]

Hi.
This patch adds support for setting the alignment of variables in
libgccjit.

I was wondering if I should change it so that it takes/returns bytes
instead of bits.
What do you think?

Thanks for the review.
From ebdb6905f23ddef28292a1d71081eebb7a2a9bb9 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Tue, 25 Jan 2022 21:12:32 -0500
Subject: [PATCH] libgccjit: Add support for setting the alignment [PR104293]

2022-01-30  Antoni Boucher 

gcc/jit/
	PR jit/104293
	* docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag.
	* docs/topics/expressions.rst: Add documentation for the
	functions gcc_jit_lvalue_set_alignment and
	gcc_jit_lvalue_get_alignment.
	* jit-playback.h: New function (set_alignment).
	* jit-recording.cc: New function (set_alignment).
	* jit-recording.h: New functions (set_alignment, get_alignment)
	and new field (m_alignment).
	* libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment,
	gcc_jit_lvalue_set_alignment)
	* libgccjit.h: New functions (gcc_jit_lvalue_get_alignment,
	gcc_jit_lvalue_set_alignment)
	* libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag.

gcc/testsuite/
	PR jit/104293
	* jit.dg/all-non-failing-tests.h: Mention
	test-setting-alignment.
	* jit.dg/test-setting-alignment.c: New test.
---
 gcc/jit/docs/topics/compatibility.rst | 10 +++
 gcc/jit/docs/topics/expressions.rst   | 39 +++
 gcc/jit/jit-playback.h|  7 ++
 gcc/jit/jit-recording.cc  | 17 -
 gcc/jit/jit-recording.h   |  6 +-
 gcc/jit/libgccjit.cc  | 25 
 gcc/jit/libgccjit.h   | 19 ++
 gcc/jit/libgccjit.map | 18 ++
 gcc/testsuite/jit.dg/all-non-failing-tests.h  |  3 +
 gcc/testsuite/jit.dg/test-setting-alignment.c | 64 +++
 10 files changed, 205 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-setting-alignment.c

diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..1957399dceb 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,13 @@ thread-local storage model of a variable:
 section of a variable:
 
   * :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_24:
+
+``LIBGCCJIT_ABI_24``
+---
+``LIBGCCJIT_ABI_24`` covers the addition of functions to get and set the
+alignement of a variable:
+
+  * :func:`gcc_jit_lvalue_set_alignment`
+  * :func:`gcc_jit_lvalue_get_alignment`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..0f5f5376d8c 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,45 @@ where the rvalue is computed by reading from the storage area.
 
   #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
 
+.. function:: void
+  gcc_jit_lvalue_set_alignment (gcc_jit_lvalue *lvalue,
+int alignment)
+
+   Set the alignment of a variable.
+   The parameter ``alignment`` is in bits. Analogous to:
+
+   .. code-block:: c
+
+ int variable __attribute__((aligned (16)));
+
+   in C, but in bits instead of bytes.
+
+   This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can test for
+   its presence using
+
+   .. code-block:: c
+
+  #ifdef LIBGCCJIT_HAVE_ALIGNMENT
+
+.. function:: int
+  gcc_jit_lvalue_get_alignment (gcc_jit_lvalue *lvalue)
+
+   Return the alignment of a variable set by ``gcc_jit_lvalue_set_alignment``, in bits.
+   Return 0 if the alignment was not set. Analogous to:
+
+   .. code-block:: c
+
+ _Alignof (variable)
+
+   in C, but in bits instead of bytes.
+
+   This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can test for
+   its presence using
+
+   .. code-block:: c
+
+  #ifdef LIBGCCJIT_HAVE_ALIGNMENT
+
 Global variables
 
 
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..4a3c4a6a09b 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -701,6 +701,13 @@ public:
 set_decl_section_name (as_tree (), name);
   }
 
+  void
+  set_alignment (int alignment)
+  {
+  SET_DECL_ALIGN (as_tree (), alignment);
+  DECL_USER_ALIGN (as_tree ()) = 1;
+  }
+
 private:
   bool mark_addressable (location *loc);
 };
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 1e3fadfacd7..7176fb34734 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -3807,6 +3807,11 @@ void recording::lvalue::set_link_section (const char *name)
   m_link_section = new_string (name);
 }
 
+void recording::lvalue::set_alignment (int alignment)
+{
+  m_alignment = alignment;
+}
+
 /* The implementation of class gcc::jit::recording::param.  */
 
 /* Implementation of pure virtual hook recording::memento::replay_into
@@ -4673,6 +4678,9 @@ recording::global::

Re: [PATCH] sh-linux fix target cpu

[Oleg Endo]

On Fri, 2022-01-28 at 15:18 -0700, Jeff Law via Gcc-patches wrote:
> 
> On 1/12/2022 2:02 AM, Yoshinori Sato wrote:
> > sh-linux not supported any SH1 and SH2a little-endian.
> > Add exceptios it.
> > 
> > gcc/ChangeLog:
> > 
> > * config/sh/t-linux (MULTILIB_EXCEPTIONS): Add m1, mb/m1 and m2a.
> Thanks.  Technically this is probably too late to make gcc-12 as we're 
> in stage4 (regression fixes only).  BUt it was posted during stage3 
> (general bugfixing) and is very very low risk.
> 
> I went ahead and committed it for you.
> 
> Thanks, and sorry for the delays.


Thanks, Jeff!

Cheers,
Oleg