Re: [PATCH] libstdc++: Make PSTL algorithms accept C++20 iterators [PR110512]

2024-01-13 Thread Pilar Latiesa
Hi Jonathan

Thanks so much for implementing this.

There are a couple of typos in the patch description:
's/C==17RandomAccessIterator/Cpp17RandomAccessIterator/' and
's/__or_/__and_/'.

I've applied your patch localy and it works fine for all my use cases,
which admitedly simply consist of using views::zip and views::enumerate
with std::for_each. My tbb version is 2020.1.


Unrelated to your patch, with GCC 14, I'm getting a ton of notes for code
like:

void f(std::vector &v)
  { std::for_each(std::execution::par, v.begin(), v.end(), [](int &i) { i
*= 2; }); }

indicating that some internal functions are not vectorized.

I very much like getting warnings if an algorithm happens to fall back to
its serial version, but in this case I didn't even asked for (unseq)
vectorization, yet I got bunch of notes: "Vectorized algorithm
unimplemented, redirected to serial" and the algorithm itself is indeed
parallelized.

The notes are so confusing that I would suggest undefining
_PSTL_USAGE_WARNINGS for G++ (in fact, I don't understand the logic that
uses this macro in pstl_config.h).


[PATCH] lower-bitint: Fix up handle_operand_addr INTEGER_CST handling [PR113361]

2024-01-13 Thread Jakub Jelinek
Hi!

As the testcase shows, the INTEGER_CST handling in handle_operand_addr
(i.e. what is used when passing address of an integer to a bitint library
routine) wasn't correct.  If the minimum precision to represent an
INTEGER_CST is smaller or equal to limb_prec, the code correctly uses
m_limb_type; if the minimum precision of a _BitInt INTEGER_CST is large
enough such that the bitint is middle, large or huge, everything is fine
too.  But the code wasn't handling correctly e.g. __int128 constants which
need more than limb_prec bits or _BitInt constants which on the architecture
are considered small (say have DImode limb_mode, TImode abi_limb_mode and
for [65, 128] bits use TImode scalar like the proposed aarch64 patch).
Best would be to use an array of 2/3/4 limbs in that case, but we'd need to
convert the INTEGER_CST to a CONSTRUCTOR in the right endianity etc.,
so the code was using mid_min_prec to enforce a middle _BitInt precision.
Except that mid_min_prec can be 0 and not computed yet, or it doesn't have
to be the smallest middle _BitInt precision, just the smallest so far
encountered.  So, on the testcase one possibility was that it used precision
65 from mid_min_prec, even when the INTEGER_CST actually needed larger
minimum precision (96 bits at least), or crashed when mid_min_prec was 0.

The patch fixes it in 2 hunks, the first makes sure we actually try to
create a BITINT_TYPE for the > limb_prec cases like __int128, and the second
instead of using mid_min_prec attempts to increase mp precision until it
isn't small anymore.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-01-13  Jakub Jelinek  

PR tree-optimization/113361
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
Fix up determination of the type for > limb_prec constants.

* gcc.dg/torture/bitint-47.c: New test.

--- gcc/gimple-lower-bitint.cc.jj   2024-01-12 11:23:12.0 +0100
+++ gcc/gimple-lower-bitint.cc  2024-01-13 00:18:19.255889866 +0100
@@ -2227,7 +2227,9 @@ bitint_large_huge::handle_operand_addr (
   mp = CEIL (min_prec, limb_prec) * limb_prec;
   if (mp == 0)
mp = 1;
-  if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op)))
+  if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op))
+ && (TREE_CODE (TREE_TYPE (op)) == BITINT_TYPE
+ || TYPE_PRECISION (TREE_TYPE (op)) <= limb_prec))
type = TREE_TYPE (op);
   else
type = build_bitint_type (mp, 1);
@@ -2237,11 +2239,15 @@ bitint_large_huge::handle_operand_addr (
  if (TYPE_PRECISION (type) <= limb_prec)
type = m_limb_type;
  else
-   /* This case is for targets which e.g. have 64-bit
-  limb but categorize up to 128-bits _BitInts as
-  small.  We could use type of m_limb_type[2] and
-  similar instead to save space.  */
-   type = build_bitint_type (mid_min_prec, 1);
+   {
+ while (bitint_precision_kind (mp) == bitint_prec_small)
+   mp += limb_prec;
+ /* This case is for targets which e.g. have 64-bit
+limb but categorize up to 128-bits _BitInts as
+small.  We could use type of m_limb_type[2] and
+similar instead to save space.  */
+ type = build_bitint_type (mp, 1);
+   }
}
   if (prec_stored)
{
--- gcc/testsuite/gcc.dg/torture/bitint-47.c.jj 2024-01-13 00:23:40.627562314 
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-47.c2024-01-13 00:25:35.571025508 
+0100
@@ -0,0 +1,31 @@
+/* PR tree-optimization/113361 */
+/* { dg-do run { target { bitint && int128 } } } */
+/* { dg-options "-std=gnu23" } */
+/* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
+/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+int
+foo (_BitInt(65) x)
+{
+  return __builtin_mul_overflow_p ((__int128) 0x << 64, x, 
(_BitInt(129)) 0);
+}
+
+int
+bar (_BitInt(63) x)
+{
+  return __builtin_mul_overflow_p ((__int128) 0x << 64, x, 
(_BitInt(129)) 0);
+}
+#endif
+
+int
+main ()
+{
+#if __BITINT_MAXWIDTH__ >= 129
+  if (!foo (5167856845))
+__builtin_abort ();
+  if (!bar (5167856845))
+__builtin_abort ();
+#endif
+  return 0;
+}

Jakub



Re: [PATCH][testsuite]: Make bitint early vect test more accurate

2024-01-13 Thread Jakub Jelinek
On Wed, Jan 10, 2024 at 06:07:16PM +, Tamar Christina wrote:
> --- a/gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c

When the testcase was being adjusted for unsigned long -> unsigned long long,
two spots using long weren't changed to long long, so the testcase still warns
about UB in shifts.

Excess errors:
.../gcc/gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c:28:48: 
warning: right shift count >= width of type [-Wshift-count-overflow]

Fixed thusly, committed to trunk as obvious.

2024-01-13  Jakub Jelinek  

PR tree-optimization/113287
* gcc.dg/vect/vect-early-break_100-pr113287.c: Use long long instead
of long.

--- gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c.jj
2024-01-12 17:02:46.176055981 +0100
+++ gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c   2024-01-13 
10:30:25.452872016 +0100
@@ -18,14 +18,14 @@ foo (void)
 {
   unsigned long long r[142];
   bar (r);
-  unsigned long long v = ((long) r[0] >> 31);
+  unsigned long long v = ((long long) r[0] >> 31);
   if (v + 1 > 1)
 return 1;
   for (unsigned long long i = 1; i <= 140; ++i)
 if (r[i] != v)
   return 1;
   unsigned long long w = r[141];
-  if ((unsigned long long) (((long) (w << 60)) >> 60) != v)
+  if ((unsigned long long) (((long long) (w << 60)) >> 60) != v)
 return 1;
   return 0;
 }



Jakub



Re: [PATCH] lower-bitint: Fix up handle_operand_addr INTEGER_CST handling [PR113361]

2024-01-13 Thread Richard Biener



> Am 13.01.2024 um 10:44 schrieb Jakub Jelinek :
> 
> Hi!
> 
> As the testcase shows, the INTEGER_CST handling in handle_operand_addr
> (i.e. what is used when passing address of an integer to a bitint library
> routine) wasn't correct.  If the minimum precision to represent an
> INTEGER_CST is smaller or equal to limb_prec, the code correctly uses
> m_limb_type; if the minimum precision of a _BitInt INTEGER_CST is large
> enough such that the bitint is middle, large or huge, everything is fine
> too.  But the code wasn't handling correctly e.g. __int128 constants which
> need more than limb_prec bits or _BitInt constants which on the architecture
> are considered small (say have DImode limb_mode, TImode abi_limb_mode and
> for [65, 128] bits use TImode scalar like the proposed aarch64 patch).
> Best would be to use an array of 2/3/4 limbs in that case, but we'd need to
> convert the INTEGER_CST to a CONSTRUCTOR in the right endianity etc.,
> so the code was using mid_min_prec to enforce a middle _BitInt precision.
> Except that mid_min_prec can be 0 and not computed yet, or it doesn't have
> to be the smallest middle _BitInt precision, just the smallest so far
> encountered.  So, on the testcase one possibility was that it used precision
> 65 from mid_min_prec, even when the INTEGER_CST actually needed larger
> minimum precision (96 bits at least), or crashed when mid_min_prec was 0.
> 
> The patch fixes it in 2 hunks, the first makes sure we actually try to
> create a BITINT_TYPE for the > limb_prec cases like __int128, and the second
> instead of using mid_min_prec attempts to increase mp precision until it
> isn't small anymore.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Richard 

> 2024-01-13  Jakub Jelinek  
> 
>PR tree-optimization/113361
>* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
>Fix up determination of the type for > limb_prec constants.
> 
>* gcc.dg/torture/bitint-47.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj2024-01-12 11:23:12.0 +0100
> +++ gcc/gimple-lower-bitint.cc2024-01-13 00:18:19.255889866 +0100
> @@ -2227,7 +2227,9 @@ bitint_large_huge::handle_operand_addr (
>   mp = CEIL (min_prec, limb_prec) * limb_prec;
>   if (mp == 0)
>mp = 1;
> -  if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op)))
> +  if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op))
> +  && (TREE_CODE (TREE_TYPE (op)) == BITINT_TYPE
> +  || TYPE_PRECISION (TREE_TYPE (op)) <= limb_prec))
>type = TREE_TYPE (op);
>   else
>type = build_bitint_type (mp, 1);
> @@ -2237,11 +2239,15 @@ bitint_large_huge::handle_operand_addr (
>  if (TYPE_PRECISION (type) <= limb_prec)
>type = m_limb_type;
>  else
> -/* This case is for targets which e.g. have 64-bit
> -   limb but categorize up to 128-bits _BitInts as
> -   small.  We could use type of m_limb_type[2] and
> -   similar instead to save space.  */
> -type = build_bitint_type (mid_min_prec, 1);
> +{
> +  while (bitint_precision_kind (mp) == bitint_prec_small)
> +mp += limb_prec;
> +  /* This case is for targets which e.g. have 64-bit
> + limb but categorize up to 128-bits _BitInts as
> + small.  We could use type of m_limb_type[2] and
> + similar instead to save space.  */
> +  type = build_bitint_type (mp, 1);
> +}
>}
>   if (prec_stored)
>{
> --- gcc/testsuite/gcc.dg/torture/bitint-47.c.jj2024-01-13 
> 00:23:40.627562314 +0100
> +++ gcc/testsuite/gcc.dg/torture/bitint-47.c2024-01-13 00:25:35.571025508 
> +0100
> @@ -0,0 +1,31 @@
> +/* PR tree-optimization/113361 */
> +/* { dg-do run { target { bitint && int128 } } } */
> +/* { dg-options "-std=gnu23" } */
> +/* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +#if __BITINT_MAXWIDTH__ >= 129
> +int
> +foo (_BitInt(65) x)
> +{
> +  return __builtin_mul_overflow_p ((__int128) 0x << 64, x, 
> (_BitInt(129)) 0);
> +}
> +
> +int
> +bar (_BitInt(63) x)
> +{
> +  return __builtin_mul_overflow_p ((__int128) 0x << 64, x, 
> (_BitInt(129)) 0);
> +}
> +#endif
> +
> +int
> +main ()
> +{
> +#if __BITINT_MAXWIDTH__ >= 129
> +  if (!foo (5167856845))
> +__builtin_abort ();
> +  if (!bar (5167856845))
> +__builtin_abort ();
> +#endif
> +  return 0;
> +}
> 
>Jakub
> 


Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

2024-01-13 Thread Jonathan Wakely
On Sat, 13 Jan 2024 at 00:06, Patrick Palka  wrote:
>
> On Fri, 12 Jan 2024, Jonathan Wakely wrote:
>
> > On Fri, 12 Jan 2024 at 18:33, Patrick Palka  wrote:
> > >
> > > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka  wrote:
> > > > >
> > > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> > > > >
> > > > > > I'd like to commit this to trunk for GCC 14. Please take a look.
> > > > > >
> > > > > > -- >8 --
> > > > > >
> > > > > > This is the last part of PR libstdc++/108822 implementing P2255R2, 
> > > > > > which
> > > > > > makes it ill-formed to create a std::tuple that would bind a 
> > > > > > reference
> > > > > > to a temporary.
> > > > > >
> > > > > > The dangling checks are implemented as deleted constructors for 
> > > > > > C++20
> > > > > > and higher, and as Debug Mode static assertions in the constructor 
> > > > > > body
> > > > > > for older standards. This is similar to the r13-6084-g916ce577ad109b
> > > > > > changes for std::pair.
> > > > > >
> > > > > > As part of this change, I've reimplemented most of std::tuple for 
> > > > > > C++20,
> > > > > > making use of concepts to replace the enable_if constraints, and 
> > > > > > using
> > > > > > conditional explicit to avoid duplicating most constructors. We 
> > > > > > could
> > > > > > use conditional explicit for the C++11 implementation too (with 
> > > > > > pragmas
> > > > > > to disables the -Wc++17-extensions warnings), but that should be 
> > > > > > done as
> > > > > > a stage 1 change for GCC 15 rather than now.
> > > > > >
> > > > > > The partial specialization for std::tuple is no longer used 
> > > > > > for
> > > > > > C++20 (or more precisely, for a C++20 compiler that supports 
> > > > > > concepts
> > > > > > and conditional explicit). The additional constructors and 
> > > > > > assignment
> > > > > > operators that take std::pair arguments have been added to the C++20
> > > > > > implementation of the primary template, with sizeof...(_Elements)==2
> > > > > > constraints. This avoids reimplementing all the other constructors 
> > > > > > in
> > > > > > the std::tuple partial specialization to use concepts. This 
> > > > > > way
> > > > > > we avoid four implementations of every constructor and only have 
> > > > > > three!
> > > > > > (The primary template has an implementation of each constructor for
> > > > > > C++11 and another for C++20, and the tuple specialization 
> > > > > > has an
> > > > > > implementation of each for C++11, so that's three for each 
> > > > > > constructor.)
> > > > > >
> > > > > > In order to make the constraints more efficient on the C++20 
> > > > > > version of
> > > > > > the default constructor I've also added a variable template for the
> > > > > > __is_implicitly_default_constructible trait, implemented using 
> > > > > > concepts.
> > > > > >
> > > > > > libstdc++-v3/ChangeLog:
> > > > > >
> > > > > >   PR libstdc++/108822
> > > > > >   * include/std/tuple (tuple): Add checks for dangling 
> > > > > > references.
> > > > > >   Reimplement constraints and constant expressions using C++20
> > > > > >   features.
> > > > > >   * include/std/type_traits [C++20]
> > > > > >   (__is_implicitly_default_constructible_v): Define.
> > > > > >   (__is_implicitly_default_constructible): Use variable 
> > > > > > template.
> > > > > >   * testsuite/20_util/tuple/dangling_ref.cc: New test.
> > > > > > ---
> > > > > >  libstdc++-v3/include/std/tuple| 1021 
> > > > > > -
> > > > > >  libstdc++-v3/include/std/type_traits  |   11 +
> > > > > >  .../testsuite/20_util/tuple/dangling_ref.cc   |  105 ++
> > > > > >  3 files changed, 841 insertions(+), 296 deletions(-)
> > > > > >  create mode 100644 
> > > > > > libstdc++-v3/testsuite/20_util/tuple/dangling_ref.cc
> > > > > >
> > > > > > diff --git a/libstdc++-v3/include/std/tuple 
> > > > > > b/libstdc++-v3/include/std/tuple
> > > > > > index 50e11843757..cd05b638923 100644
> > > > > > --- a/libstdc++-v3/include/std/tuple
> > > > > > +++ b/libstdc++-v3/include/std/tuple
> > > > > > @@ -752,11 +752,467 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > > > >template
> > > > > >  class tuple : public _Tuple_impl<0, _Elements...>
> > > > > >  {
> > > > > > -  typedef _Tuple_impl<0, _Elements...> _Inherited;
> > > > > > +  using _Inherited = _Tuple_impl<0, _Elements...>;
> > > > > >
> > > > > >template
> > > > > >   using _TCC = _TupleConstraints<_Cond, _Elements...>;
> > > > >
> > > > > I guess this should be moved into the #else branch if it's not used in
> > > > > the new impl.
> > > >
> > > > Ah yes, I left them there until I was sure I wouldn't need them ...
> > > > then didn't move them when I didn't need them.
> > > >
> > > > >
> > > > > >
> > > > > > +#if __cpp_concepts && __cpp_conditional_explicit // >= C++20
> > > > > > +  template
> > > > > > + static consteval bool
> > > > > > + __cons

[PATCH v2] libstdc++: Update tzdata to 2023d

2024-01-13 Thread Jonathan Wakely
On Fri, 12 Jan 2024 at 22:59, Jonathan Wakely wrote:
>
> It would be good to update the bundled tzdata for GCC 14.1 and 13.3

The expiry date for the hardcoded leapseconds list should be updated
too, as there's a new date in the file in the tzdata distro. There are
no new leap seconds though, just a new "this list is valid until ..."
date.

Tested x86_64-linux and aarch64-linux.
commit e65bd5d069ad27ce01854ad52224bc0186c924cf
Author: Jonathan Wakely 
Date:   Fri Jan 12 16:57:41 2024

libstdc++: Update tzdata to 2023d

Import the new 2023d tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).

libstdc++-v3/ChangeLog:

* src/c++20/tzdata.zi: Import new file from 2023d release.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds)
Update expiry date for leap seconds list.

diff --git a/libstdc++-v3/src/c++20/tzdata.zi b/libstdc++-v3/src/c++20/tzdata.zi
index b522e395326..4e01359010c 100644
--- a/libstdc++-v3/src/c++20/tzdata.zi
+++ b/libstdc++-v3/src/c++20/tzdata.zi
@@ -1,4 +1,4 @@
-# version 2023c
+# version 2023d
 # This zic input file is in the public domain.
 R d 1916 o - Jun 14 23s 1 S
 R d 1916 1919 - O Su>=1 23s 0 -
@@ -394,7 +394,12 @@ Z Antarctica/Casey 0 - -00 1969
 8 - +08 2019 O 4 3
 11 - +11 2020 Mar 8 3
 8 - +08 2020 O 4 0:1
-11 - +11
+11 - +11 2021 Mar 14
+8 - +08 2021 O 3 0:1
+11 - +11 2022 Mar 13
+8 - +08 2022 O 2 0:1
+11 - +11 2023 Mar 9 3
+8 - +08
 Z Antarctica/Davis 0 - -00 1957 Ja 13
 7 - +07 1964 N
 0 - -00 1969 F
@@ -410,6 +415,11 @@ R Tr 2005 ma - Mar lastSu 1u 2 +02
 R Tr 2004 ma - O lastSu 1u 0 +00
 Z Antarctica/Troll 0 - -00 2005 F 12
 0 Tr %s
+Z Antarctica/Vostok 0 - -00 1957 D 16
+7 - +07 1994 F
+0 - -00 1994 N
+7 - +07 2023 D 18 2
+5 - +05
 Z Antarctica/Rothera 0 - -00 1976 D
 -3 - -03
 Z Asia/Kabul 4:36:48 - LMT 1890
@@ -1050,13 +1060,13 @@ R P 2070 o - O 4 2 0 -
 R P 2071 o - S 19 2 0 -
 R P 2072 o - S 10 2 0 -
 R P 2072 o - O 15 2 1 S
+R P 2072 ma - O Sa<=30 2 0 -
 R P 2073 o - S 2 2 0 -
 R P 2073 o - O 7 2 1 S
 R P 2074 o - Au 18 2 0 -
 R P 2074 o - S 29 2 1 S
 R P 2075 o - Au 10 2 0 -
 R P 2075 o - S 14 2 1 S
-R P 2075 ma - O Sa<=30 2 0 -
 R P 2076 o - Jul 25 2 0 -
 R P 2076 o - S 5 2 1 S
 R P 2077 o - Jul 17 2 0 -
@@ -1831,10 +1841,12 @@ Z America/Danmarkshavn -1:14:40 - LMT 1916 Jul 28
 Z America/Scoresbysund -1:27:52 - LMT 1916 Jul 28
 -2 - -02 1980 Ap 6 2
 -2 c -02/-01 1981 Mar 29
--1 E -01/+00
+-1 E -01/+00 2024 Mar 31
+-2 E -02/-01
 Z America/Nuuk -3:26:56 - LMT 1916 Jul 28
 -3 - -03 1980 Ap 6 2
--3 E -03/-02 2023 O 29 1u
+-3 E -03/-02 2023 Mar 26 1u
+-2 - -02 2023 O 29 1u
 -2 E -02/-01
 Z America/Thule -4:35:8 - LMT 1916 Jul 28
 -4 Th A%sT
@@ -4185,7 +4197,6 @@ L America/Puerto_Rico America/Tortola
 L Pacific/Port_Moresby Antarctica/DumontDUrville
 L Pacific/Auckland Antarctica/McMurdo
 L Asia/Riyadh Antarctica/Syowa
-L Asia/Urumqi Antarctica/Vostok
 L Europe/Berlin Arctic/Longyearbyen
 L Asia/Riyadh Asia/Aden
 L Asia/Qatar Asia/Bahrain
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index d22cea7e070..6b86329ecac 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -1136,8 +1136,8 @@ namespace std::chrono
   pair, bool>
   tzdb_list::_Node::_S_read_leap_seconds()
   {
-// This list is valid until at least 2023-12-28 00:00:00 UTC.
-auto expires = sys_days{2023y/12/28};
+// This list is valid until at least 2024-06-28 00:00:00 UTC.
+auto expires = sys_days{2024y/6/28};
 vector leaps
 {
   (leap_second)  78796800, // 1 Jul 1972


Re: [PATCH] libstdc++: Make PSTL algorithms accept C++20 iterators [PR110512]

2024-01-13 Thread Jonathan Wakely
On Sat, 13 Jan 2024 at 09:36, Pilar Latiesa  wrote:
>
> Hi Jonathan
>
> Thanks so much for implementing this.
>
> There are a couple of typos in the patch description: 
> 's/C==17RandomAccessIterator/Cpp17RandomAccessIterator/' and 
> 's/__or_/__and_/'.

Thanks for the comments, I'll fix those.

>
> I've applied your patch localy and it works fine for all my use cases, which 
> admitedly simply consist of using views::zip and views::enumerate with 
> std::for_each. My tbb version is 2020.1.

Thanks for checking it, all feedback is useful.

>
> Unrelated to your patch, with GCC 14, I'm getting a ton of notes for code 
> like:
>
> void f(std::vector &v)
>   { std::for_each(std::execution::par, v.begin(), v.end(), [](int &i) { i *= 
> 2; }); }
>
> indicating that some internal functions are not vectorized.
>
> I very much like getting warnings if an algorithm happens to fall back to its 
> serial version, but in this case I didn't even asked for (unseq) 
> vectorization, yet I got bunch of notes: "Vectorized algorithm unimplemented, 
> redirected to serial" and the algorithm itself is indeed parallelized.
>
> The notes are so confusing that I would suggest undefining 
> _PSTL_USAGE_WARNINGS for G++ (in fact, I don't understand the logic that uses 
> this macro in pstl_config.h).

Yeah, I've seen some of those, and I'm afraid I don't have any ideas
about them for now. Could you report it to bugzilla so we don't forget
to look into it? Thanks!



Re: [PATCH] Pass GUILE down to subdirectories

2024-01-13 Thread Andrew Burgess
Tom Tromey  writes:

> When I enable cgen rebuilding in the binutils-gdb tree, the default is
> to run cgen using 'guile'.  However, on my host, guile is guile 2.2,
> which doesn't work for me -- I have to use guile3.0.
>
> This patch arranges to pass "GUILE" down to subdirectories, so I can
> use 'make GUILE=guile3.0'.
>
> ChangeLog
> 2023-12-30  Tom Tromey  
>
>   * Makefile.in: Rebuild.
>   * Makefile.tpl (BASE_EXPORTS): Add GUILE.
>   (GUILE): New variable.
>   * Makefile.def (flags_to_pass): Add GUILE.
> ---
>  ChangeLog| 7 +++
>  Makefile.def | 1 +
>  Makefile.in  | 8 ++--
>  Makefile.tpl | 7 +--
>  4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile.def b/Makefile.def
> index 662e50fdc18..792919e561c 100644
> --- a/Makefile.def
> +++ b/Makefile.def
> @@ -310,6 +310,7 @@ flags_to_pass = { flag= GNATBIND ; };
>  flags_to_pass = { flag= GNATMAKE ; };
>  flags_to_pass = { flag= GDC ; };
>  flags_to_pass = { flag= GDCFLAGS ; };
> +flags_to_pass = { flag= GUILE ; };
>  
>  // Target tools
>  flags_to_pass = { flag= AR_FOR_TARGET ; };
> diff --git a/Makefile.in b/Makefile.in
> index 48320bb549e..9a58d5a4f20 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -3,7 +3,7 @@
>  #
>  # Makefile for directory with subdirs to build.
>  #   Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
> -#   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 
> 2011
> +#   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 
> 2011, 2023
>  #   Free Software Foundation
>  #
>  # This file is free software; you can redistribute it and/or modify
> @@ -143,7 +143,8 @@ BASE_EXPORTS = \
>   M4="$(M4)"; export M4; \
>   SED="$(SED)"; export SED; \
>   AWK="$(AWK)"; export AWK; \
> - MAKEINFO="$(MAKEINFO)"; export MAKEINFO;
> + MAKEINFO="$(MAKEINFO)"; export MAKEINFO; \
> + GUILE="$(GUILE)"; export GUILE;
>  
>  # This is the list of variables to export in the environment when
>  # configuring subdirectories for the build system.
> @@ -450,6 +451,8 @@ GM2FLAGS = $(CFLAGS)
>  
>  PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
>  
> +GUILE = guile

Hi Tom,

This change is causing some problems for me.

One of my build machines has 2 versions of guile installed.  One is
guile 2.0.14 and the other is guile 2.2.21.

When GDB configures itself the configure script figures out that it
should use 2.2.21 to compile the guile libraries that GDB uses.

However, when we actually build the guile libraries we do use guild2.2,
but due to this 'GUILE = guile' line, guild2.2 uses guile 2.0.14 in
order to perform the compile (I guess, I don't know the details of how
guile compilation works).

Unfortunately guile 2.0.14 compiles in a way which is not compatible
with how GDB then tries to load the guile library.

Maybe better to show you what's going on:

  $ pwd
  /tmp/binutils-gdb/build/gdb/data-directory/guile
  $ GUILE=guile /usr/bin/guild2.2 compile -Warity-mismatch -Wformat 
-Wunused-toplevel -L . -o ./gdb.go ./gdb.scm
  wrote `./gdb.go'
  $ file gdb.go
  gdb.go: Guile Object, little endian, 64bit, bytecode v2.0
  $ GUILE=guile2.2 /usr/bin/guild2.2 compile -Warity-mismatch -Wformat 
-Wunused-toplevel -L . -o ./gdb.go ./gdb.scm
  wrote `./gdb.go'
  $ file gdb.go
  gdb.go: ELF 64-bit LSB shared object, no machine, version 1 (embedded), 
dynamically linked, with debug_info, not stripped

The first compile uses GUILE=guile, so I use guile 2.0.14, which results
in a non-ELF being generated.  When I start GDB with this non-ELF in
place, I see this:

  $ ./gdb/gdb --data-directory ./gdb/data-directory/
  Exception caught while booting Guile.
  Error in function "load-thunk-from-memory":
  not an ELF file
  ./gdb/gdb: warning: Could not complete Guile gdb module initialization from:
  /tmp/binutils-gdb/build/gdb/data-directory/guile/gdb/boot.scm.
  Limited Guile support is available.
  Suggest passing --data-directory=/path/to/gdb/data-directory.
  GDB Version: 15.1
  
  (gdb) 

The second compile, with GUILE=guile2.2 results in an ELF being
generated, and with this in place GDB starts just fine.

Now, clearly the obvious answer is: don't have such an old, out of date
version of guile installed.  But I think there's a bigger issue here.
As guild version X will by default pick up the corresponding version of
guile, shouldn't that be the default behaviour?

My proposal would be that we change the line 'GUILE = guile' to instead
be just 'GUILE ='.

With this in place I can still override the choice of guile executable
with:

  make GUILE=guile

but, if I don't do this then instead of forcing 'guile' as the default,
we allow the guild compiler to pick its own default, just as we did
before.

Thoughts?

Thanks,
Andrew

---

commit 5230132e2a49ee6603d6713796fb72c418b83e30
Author: Andrew Burgess 
Date:   Sat Jan 13 11:15:13 2024 +

don't force 'guile' as the default guile executable

After commit:

  commit 

[PATCH v2] libstdc++: Implement C++26 std::text_encoding [PR113318]

2024-01-13 Thread Jonathan Wakely
Patch v2, with more tests. This fixes a bug in lookup by name where if
an alias was matched then the aliases() view wouldn't contain the
primary name or other aliases earlier in the table.

It also optimizes text_encoding::environment_is so it constructs an
encoding by ID and then only matches the environment's encoding against
that object's aliases, not every string in the table.

There's also a fast path for text_encoding("UTF-8") so we don't search
the table for that case.

More tests still needed...

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/113318
* acinclude.m4 (GLIBCXX_CHECK_TEXT_ENCODING): Define.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_TEXT_ENCODING.
* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/bits/locale_classes.h (locale::encoding): Declare new
member function.
* include/bits/unicode.h (__charset_alias_match): New function.
* include/bits/text_encoding-data.h: New file.
* include/bits/version.def (text_encoding): Define.
* include/bits/version.h: Regenerate.
* include/std/text_encoding: New file.
* src/c++26/Makefile.am: Add test_encoding.cc.
* src/c++26/Makefile.in: Regenerate.
* src/c++26/text_encoding.cc: New file.
* python/libstdcxx/v6/printers.py (StdTextEncodingPrinter): New
printer.
* scripts/gen_text_encoding_data.py: New file.
* testsuite/ext/unicode/charset_alias_match.cc: New test.
* testsuite/std/text_encoding/cons.cc: New test.
* testsuite/std/text_encoding/requirements.cc: New test.
---
 libstdc++-v3/acinclude.m4 |  28 +
 libstdc++-v3/config.h.in  |   3 +
 libstdc++-v3/configure|  54 ++
 libstdc++-v3/configure.ac |   3 +
 libstdc++-v3/include/Makefile.am  |   2 +
 libstdc++-v3/include/Makefile.in  |   2 +
 libstdc++-v3/include/bits/locale_classes.h|  14 +
 .../include/bits/text_encoding-data.h | 902 ++
 libstdc++-v3/include/bits/unicode.h   | 157 ++-
 libstdc++-v3/include/bits/version.def |  10 +
 libstdc++-v3/include/bits/version.h   |  13 +-
 libstdc++-v3/include/std/text_encoding| 704 ++
 libstdc++-v3/python/libstdcxx/v6/printers.py  |  17 +
 .../scripts/gen_text_encoding_data.py |  70 ++
 libstdc++-v3/src/c++26/Makefile.am|   2 +-
 libstdc++-v3/src/c++26/Makefile.in|   4 +-
 libstdc++-v3/src/c++26/text_encoding.cc   |  91 ++
 .../ext/unicode/charset_alias_match.cc|  18 +
 .../testsuite/std/text_encoding/cons.cc   | 106 ++
 .../std/text_encoding/requirements.cc |  31 +
 20 files changed, 2226 insertions(+), 5 deletions(-)
 create mode 100644 libstdc++-v3/include/bits/text_encoding-data.h
 create mode 100644 libstdc++-v3/include/std/text_encoding
 create mode 100755 libstdc++-v3/scripts/gen_text_encoding_data.py
 create mode 100644 libstdc++-v3/src/c++26/text_encoding.cc
 create mode 100644 libstdc++-v3/testsuite/ext/unicode/charset_alias_match.cc
 create mode 100644 libstdc++-v3/testsuite/std/text_encoding/cons.cc
 create mode 100644 libstdc++-v3/testsuite/std/text_encoding/requirements.cc

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index aa2cc4af52b..f9ba7ef744b 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5821,6 +5821,34 @@ AC_LANG_SAVE
   AC_LANG_RESTORE
 ])
 
+dnl
+dnl Check whether the dependencies for std::text_encoding are available.
+dnl
+dnl Defines:
+dnl   _GLIBCXX_USE_NL_LANGINFO_L if nl_langinfo_l is in .
+dnl
+AC_DEFUN([GLIBCXX_CHECK_TEXT_ENCODING], [
+AC_LANG_SAVE
+  AC_LANG_CPLUSPLUS
+
+  AC_MSG_CHECKING([whether nl_langinfo_l is defined in ])
+  AC_TRY_COMPILE([
+  #include 
+  #include 
+  ],[
+locale_t loc = newlocale(LC_ALL_MASK, "", (locale_t)0);
+const char* enc = nl_langinfo_l(CODESET, loc);
+freelocale(loc);
+  ], [ac_nl_langinfo_l=yes], [ac_nl_langinfo_l=no])
+  AC_MSG_RESULT($ac_nl_langinfo_l)
+  if test "$ac_nl_langinfo_l" = yes; then
+AC_DEFINE_UNQUOTED(_GLIBCXX_USE_NL_LANGINFO_L, 1,
+  [Define if nl_langinfo_l should be used for std::text_encoding.])
+  fi
+
+  AC_LANG_RESTORE
+])
+
 # Macros from the top-level gcc directory.
 m4_include([../config/gc++filt.m4])
 m4_include([../config/tls.m4])
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index c8b36333019..c68cac4f345 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -557,6 +557,9 @@ GLIBCXX_CHECK_INIT_PRIORITY
 # For __basic_file::native_handle()
 GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES
 
+# For std::text_encoding
+GLIBCXX_CHECK_TEXT_ENCODING
+
 # Define documentation rules conditionally.
 
 # See if makeinfo has been installed and is modern enough
diff --git a/libstdc++-v3/include/

Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

2024-01-13 Thread Xi Ruoyao
在 2024-01-13星期六的 15:01 +0800,chenglulu写道:
> 
> 在 2024/1/12 下午7:42, Xi Ruoyao 写道:
> > 在 2024-01-12星期五的 09:46 +0800,chenglulu写道:
> > 
> > > > I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS:
> > > > we need a target hook to tell the generic code
> > > > UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll
> > > > see millions lines of messages like
> > > > 
> > > > ../../gcc/gcc/tree.h:4171:1: note: non-delegitimized UNSPEC
> > > > UNSPEC_LA_PCREL_64_PART1 (42) found in variable location
> > > I build GCC with -mcmodel=extreme in BOOT_CFLAGS, but I haven't 
> > > reproduced the problem you mentioned.
> > > 
> > >  $ ../configure --host=loongarch64-linux-gnu 
> > > --target=loongarch64-linux-gnu --build=loongarch64-linux-gnu \
> > >  --with-arch=loongarch64 --with-abi=lp64d --enable-tls 
> > > --enable-languages=c,c++,fortran,lto --enable-plugin \
> > >  --disable-multilib --disable-host-shared --enable-bootstrap 
> > > --enable-checking=release
> > >  $ make BOOT_FLAGS="-mcmodel=extreme"
> > > 
> > > What did I do wrong?:-(
> > BOOT_CFLAGS, not BOOT_FLAGS :).
> > 
> This is so strange. My compilation here stopped due to syntax problems,
> 
> and I still haven't reproduced the information you mentioned about 
> UNSPEC_LA_PCREL_64_PART1.

I used:

../gcc/configure --with-system-zlib --disable-fixincludes \
 --enable-default-ssp --enable-default-pie \
 --disable-werror --disable-multilib \
 --prefix=/home/xry111/gcc-dev

and then

make STAGE1_{C,CXX}FLAGS="-O2 -g" -j8 \
 BOOT_{C,CXX}FLAGS="-O2 -g -mcmodel=extreme" &| tee gcc-build.log

I guess "-g" is needed to reproduce the issue as well as the messages
were produced in dwarf generation.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

2024-01-13 Thread Xi Ruoyao
在 2024-01-13星期六的 15:28 +0800,chenxiaolong写道:
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/pr104992.c: Added additional "-mlsx" compilation options.
>   * gcc.dg/signbit-2.c: Dito.
>   * gcc.dg/tree-ssa/scev-16.c: Dito.
>   * gfortran.dg/graphite/vect-pr40979.f90: Dito.
>   * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.

I don't feel it right about the changes to pr104992.c and scev-16.c
because no other architectures add special options there.  Why are we
so special?

> ---
>  gcc/testsuite/gcc.dg/pr104992.c    | 1 +
>  gcc/testsuite/gcc.dg/signbit-2.c   | 1 +
>  gcc/testsuite/gcc.dg/tree-ssa/scev-16.c    | 1 +
>  gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90    | 1 +
>  gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
>  5 files changed, 5 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
> index 82f8c75559c..a77992fa491 100644
> --- a/gcc/testsuite/gcc.dg/pr104992.c
> +++ b/gcc/testsuite/gcc.dg/pr104992.c
> @@ -1,6 +1,7 @@
>  /* PR tree-optimization/104992 */
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
> +/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
>  
>  #define vector __attribute__((vector_size(4*sizeof(int
>  
> diff --git a/gcc/testsuite/gcc.dg/signbit-2.c 
> b/gcc/testsuite/gcc.dg/signbit-2.c
> index 62bb4047d74..5511bb78149 100644
> --- a/gcc/testsuite/gcc.dg/signbit-2.c
> +++ b/gcc/testsuite/gcc.dg/signbit-2.c
> @@ -5,6 +5,7 @@
>  /* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-* 
> x86_64-*-* } } } */
>  /* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
>  /* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
> +/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
>  /* { dg-skip-if "no fallback for MVE" { arm_mve } } */
>  
>  #include 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> index 120f40c0b6c..06cfbbcfae5 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target vect_int } */
>  /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details" } */
> +/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
>  
>  int A[1024 * 2];
>  
> diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90 
> b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> index a42290948c4..6f2ad1166a4 100644
> --- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> +++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> @@ -1,6 +1,7 @@
>  ! { dg-do compile }
>  ! { dg-require-effective-target vect_double }
>  ! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && 
> ilp32 } } }
> +! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
>  
>  module mqc_m
>  integer, parameter, private :: longreal = selected_real_kind(15,90)
> diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f 
> b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> index 08965cc5e20..97b88821731 100644
> --- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> +++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> @@ -2,6 +2,7 @@
>  ! { dg-require-effective-target vect_double }
>  ! { dg-options "-O3 --param vect-max-peeling-for-alignment=0 
> -fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
>  ! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } 
> } }
> +! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
>  ! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
>  
>  *** RESID COMPUTES THE RESIDUAL:  R = V - AU

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Jit testsuite updates for Darwin

2024-01-13 Thread Iain Sandoe
This is a short series of patches to support non-ELF targets in
the jit tests where these use target-specific capabilities (e.g.
alias support, or scanning for assembler directives.)

An alternative would be to skip these tests for Darwin.

Tested on x86_64 Darwin, and about to test Linux,
OK for trunk if testing is also sucessful on Linux?
thanks
Iain




[PATCH 1/4] testsuite, jit: test-alias-attribute.c requires alias support.

2024-01-13 Thread Iain Sandoe
Add a dg-require-alias to cover this.

gcc/testsuite/ChangeLog:

* jit.dg/test-alias-attribute.c: Require target alias
support.

Signed-off-by: Iain Sandoe 
---
 gcc/testsuite/jit.dg/test-alias-attribute.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/jit.dg/test-alias-attribute.c 
b/gcc/testsuite/jit.dg/test-alias-attribute.c
index eb29003dfc9..4741aba5011 100644
--- a/gcc/testsuite/jit.dg/test-alias-attribute.c
+++ b/gcc/testsuite/jit.dg/test-alias-attribute.c
@@ -1,4 +1,5 @@
 /* { dg-do compile { target x86_64-*-* } } */
+/* { dg-require-alias "" } */
 
 #include 
 #include 
-- 
2.39.2 (Apple Git-143)



[PATCH 2/4] testsuite, jit: Handle whitespace in test-link-section-assembler.c.

2024-01-13 Thread Iain Sandoe
Darwin has a different .section directive that has more fields and
uses different whitespace.  Amend the whitespace in the scan-asm to
be more flexible.

gcc/testsuite/ChangeLog:

* jit.dg/test-link-section-assembler.c: Accept any whitespace
between the .section directive and its arguments.

Signed-off-by: Iain Sandoe 
---
 gcc/testsuite/jit.dg/test-link-section-assembler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/jit.dg/test-link-section-assembler.c 
b/gcc/testsuite/jit.dg/test-link-section-assembler.c
index a90b00e9a82..a78e9fd26ef 100644
--- a/gcc/testsuite/jit.dg/test-link-section-assembler.c
+++ b/gcc/testsuite/jit.dg/test-link-section-assembler.c
@@ -34,4 +34,4 @@ create_code (gcc_jit_context *ctxt, void *user_data)
 }
 
 /* { dg-final { jit-verify-output-file-was-created "" } } */
-/* { dg-final { jit-verify-assembler-output ".section  .my_section" } } */
+/* { dg-final { jit-verify-assembler-output ".section\\s.my_section" } } */
-- 
2.39.2 (Apple Git-143)



[PATCH 4/4] testsuite,jit: Handle Darwin/Mach-O in assembler tests.

2024-01-13 Thread Iain Sandoe
Several of the jit tests check for assembler-specific output
which differs on Mach-O from ELF.

This patch uses the facility to make the scans targer-dependent
and adds handling for darwin.

gcc/testsuite/ChangeLog:

* jit.dg/test-always_inline-attribute.c: Handle Darwin in
jit-verify-assembler-output.
* jit.dg/test-noinline-attribute.c: Likewise.
* jit.dg/test-setting-alignment.c: Likewise.
* jit.dg/test-used-attribute.c: Likewise.
* jit.dg/test-variable-attribute.c: Likewise.
* jit.dg/test-weak-attribute.c: Likewise.

Signed-off-by: Iain Sandoe 
---
 gcc/testsuite/jit.dg/test-always_inline-attribute.c | 10 +++---
 gcc/testsuite/jit.dg/test-noinline-attribute.c  | 10 +++---
 gcc/testsuite/jit.dg/test-setting-alignment.c   |  3 ++-
 gcc/testsuite/jit.dg/test-used-attribute.c  | 10 +++---
 gcc/testsuite/jit.dg/test-variable-attribute.c  | 10 ++
 gcc/testsuite/jit.dg/test-weak-attribute.c  |  3 ++-
 6 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/gcc/testsuite/jit.dg/test-always_inline-attribute.c 
b/gcc/testsuite/jit.dg/test-always_inline-attribute.c
index 5c3f386663f..f7201a17140 100644
--- a/gcc/testsuite/jit.dg/test-always_inline-attribute.c
+++ b/gcc/testsuite/jit.dg/test-always_inline-attribute.c
@@ -148,6 +148,10 @@ int foo () {
 
 /* { dg-final { jit-verify-output-file-was-created "" } } */
 /* Check that the "removed" function was inlined, but not the others */
-/* { dg-final { jit-verify-assembler-output-not 
".type\\s+removed,\\s+@function" } } */
-/* { dg-final { jit-verify-assembler-output 
".type\\s+not_removed,\\s+@function" } } */
-/* { dg-final { jit-verify-assembler-output ".type\\s+foo,\\s+@function" } } */
+/* { dg-final { jit-verify-assembler-output-not 
".type\\s+removed,\\s+@function" { target { ! *-*-darwin* } } } } */
+/* { dg-final { jit-verify-assembler-output 
".type\\s+not_removed,\\s+@function" { target { ! *-*-darwin* } } } } */
+/* { dg-final { jit-verify-assembler-output ".type\\s+foo,\\s+@function" { 
target { ! *-*-darwin* } } } } */
+
+/* { dg-final { jit-verify-assembler-output-not "\\n_removed:" { target 
*-*-darwin* } } } */
+/* { dg-final { jit-verify-assembler-output "\\n_not_removed:" { target 
*-*-darwin* } } } */
+/* { dg-final { jit-verify-assembler-output "\\n_foo:" { target *-*-darwin* } 
} } */
diff --git a/gcc/testsuite/jit.dg/test-noinline-attribute.c 
b/gcc/testsuite/jit.dg/test-noinline-attribute.c
index eac6cae6b6a..acfea8fc55e 100644
--- a/gcc/testsuite/jit.dg/test-noinline-attribute.c
+++ b/gcc/testsuite/jit.dg/test-noinline-attribute.c
@@ -114,6 +114,10 @@ int foo () {
 
 /* { dg-final { jit-verify-output-file-was-created "" } } */
 /* Check that the "removed" function was inlined, but not the others */
-/* { dg-final { jit-verify-assembler-output-not 
".type\\s+removed.isra.0,\\s+@function" } } */
-/* { dg-final { jit-verify-assembler-output 
".type\\s+not_removed.isra.0,\\s+@function" } } */
-/* { dg-final { jit-verify-assembler-output ".type\\s+foo,\\s+@function" } } */
+/* { dg-final { jit-verify-assembler-output-not 
".type\\s+removed.isra.0,\\s+@function" { target { ! *-*-darwin* } } } } */
+/* { dg-final { jit-verify-assembler-output 
".type\\s+not_removed.isra.0,\\s+@function" { target { ! *-*-darwin* } } } } */
+/* { dg-final { jit-verify-assembler-output ".type\\s+foo,\\s+@function" { 
target { ! *-*-darwin* } } } } */
+
+/* { dg-final { jit-verify-assembler-output-not "\\n_removed.isra.0:" { target 
*-*-darwin* } } } */
+/* { dg-final { jit-verify-assembler-output "\\n_not_removed.isra.0:" { target 
*-*-darwin* } } } */
+/* { dg-final { jit-verify-assembler-output "\\n_foo:" { target *-*-darwin* } 
} } */
diff --git a/gcc/testsuite/jit.dg/test-setting-alignment.c 
b/gcc/testsuite/jit.dg/test-setting-alignment.c
index 8489df9c6b9..14edc723f61 100644
--- a/gcc/testsuite/jit.dg/test-setting-alignment.c
+++ b/gcc/testsuite/jit.dg/test-setting-alignment.c
@@ -62,5 +62,6 @@ create_code (gcc_jit_context *ctxt, void *user_data)
 }
 
 /* { dg-final { jit-verify-output-file-was-created "" } } */
-/* { dg-final { jit-verify-assembler-output ".comm foo,4,8" } } */
+/* { dg-final { jit-verify-assembler-output ".comm foo,4,8" { target { ! 
*-*-darwin* } } } } */
+/* { dg-final { jit-verify-assembler-output ".comm\\s_foo,4,3" { target 
*-*-darwin* } } } */
 /* { dg-final { jit-verify-assembler-output "movl  -16\\\(%rbp\\\), %eax" 
} } */
diff --git a/gcc/testsuite/jit.dg/test-used-attribute.c 
b/gcc/testsuite/jit.dg/test-used-attribute.c
index cb20952c687..446c5c5c31b 100644
--- a/gcc/testsuite/jit.dg/test-used-attribute.c
+++ b/gcc/testsuite/jit.dg/test-used-attribute.c
@@ -107,6 +107,10 @@ int foo() {
 
 /* { dg-final { jit-verify-output-file-was-created "" } } */
 /* Check that the "removed" function was inlined, but not the others */
-/* { dg-final { jit-verify-assembler-output-not 
".type\\s+removed,\\s+@function" } } */

[PATCH 3/4] testsuite, jit: Allow for target-specific assembler scans.

2024-01-13 Thread Iain Sandoe
If we want to support multiple object formats and to allow for
scan-assembler tests, we need to make it possible to adjust the
tests on a per-target basis.

This adds similar mechamisms to jit-verify-assembler-output{,-not}
to those used for the general scan-assembler dg directives.

As an aside; it would, perhaps, be possible to integrate this more
with scanasm.exp (which would also give access to function body
scanning) but I did not attempt that for this patch.

After this, we can accept things like:
... { jit-verify-assembler-output-not ".." { target { ! *-*-darwin* } } } }
or
... { jit-verify-assembler-output ".." { target *-*-darwin* } } }

gcc/testsuite/ChangeLog:

* jit.dg/jit.exp: Accept target clauses in jit-verify-assembler
handling.

Signed-off-by: Iain Sandoe 
---
 gcc/testsuite/jit.dg/jit.exp | 28 
 1 file changed, 28 insertions(+)

diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 56972064d30..286cfa8192a 100644
--- a/gcc/testsuite/jit.dg/jit.exp
+++ b/gcc/testsuite/jit.dg/jit.exp
@@ -875,9 +875,23 @@ proc jit-verify-assembler { args } {
 proc jit-verify-assembler-output { args } {
 verbose "jit-verify-assembler: $args"
 
+if { [llength $args] > 3 } {
+   error "jit-verify-assembler-output: too many arguments"
+   return
+}
+
 set dg-output-text [lindex $args 0]
 verbose "dg-output-text: ${dg-output-text}"
 
+if { [llength $args] >= 2 } {
+   switch [dg-process-target [lindex $args 1]] {
+   "S" { }
+   "N" { return }
+   "F" { setup_xfail "*-*-*" }
+   "P" { }
+   }
+}
+
 upvar 2 name name
 verbose "name: $name"
 
@@ -907,9 +921,23 @@ proc jit-verify-assembler-output { args } {
 proc jit-verify-assembler-output-not { args } {
 verbose "jit-verify-assembler: $args"
 
+if { [llength $args] > 3 } {
+   error "jit-verify-assembler-output-not: too many arguments"
+   return
+}
+
 set dg-output-text [lindex $args 0]
 verbose "dg-output-text: ${dg-output-text}"
 
+if { [llength $args] >= 2 } {
+   switch [dg-process-target [lindex $args 1]] {
+   "S" { }
+   "N" { return }
+   "F" { setup_xfail "*-*-*" }
+   "P" { }
+   }
+}
+
 upvar 2 name name
 verbose "name: $name"
 
-- 
2.39.2 (Apple Git-143)



Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

2024-01-13 Thread chenglulu



在 2024/1/13 下午9:05, Xi Ruoyao 写道:

在 2024-01-13星期六的 15:01 +0800,chenglulu写道:

在 2024/1/12 下午7:42, Xi Ruoyao 写道:

在 2024-01-12星期五的 09:46 +0800,chenglulu写道:


I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS:
we need a target hook to tell the generic code
UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll
see millions lines of messages like

../../gcc/gcc/tree.h:4171:1: note: non-delegitimized UNSPEC
UNSPEC_LA_PCREL_64_PART1 (42) found in variable location

I build GCC with -mcmodel=extreme in BOOT_CFLAGS, but I haven't reproduced the 
problem you mentioned.

  $ ../configure --host=loongarch64-linux-gnu 
--target=loongarch64-linux-gnu --build=loongarch64-linux-gnu \
  --with-arch=loongarch64 --with-abi=lp64d --enable-tls 
--enable-languages=c,c++,fortran,lto --enable-plugin \
  --disable-multilib --disable-host-shared --enable-bootstrap 
--enable-checking=release
  $ make BOOT_FLAGS="-mcmodel=extreme"

What did I do wrong?:-(

BOOT_CFLAGS, not BOOT_FLAGS :).


This is so strange. My compilation here stopped due to syntax problems,

and I still haven't reproduced the information you mentioned about
UNSPEC_LA_PCREL_64_PART1.

I used:

../gcc/configure --with-system-zlib --disable-fixincludes \
  --enable-default-ssp --enable-default-pie \
  --disable-werror --disable-multilib \
  --prefix=/home/xry111/gcc-dev

and then

make STAGE1_{C,CXX}FLAGS="-O2 -g" -j8 \
  BOOT_{C,CXX}FLAGS="-O2 -g -mcmodel=extreme" &| tee gcc-build.log

I guess "-g" is needed to reproduce the issue as well as the messages
were produced in dwarf generation.


Oh, okay, I'll try this method!:-)







[PATCH 0/4] aarch64, rtl-ssa: Fix wrong code in ldp fusion pass [PR113070]

2024-01-13 Thread Alex Coplan
This patch series restores PGO+LTO bootstrap on aarch64 (with the ldp
passes enabled) and fixes wrong code (leading to a segfault) seen in
cactuBSSN_r from SPEC CPU 2017 with PGO+LTO enabled.

For an example showing what goes wrong, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070#c7

In the case that we insert a new stp insn (as opposed to re-purposing an
existing store) RTL-SSA fails to properly insert the newly-created def
of memory into the def chain and the ldp/stp pass fails to update uses
of memory immediately following an stp insn.  This can lead to alias
analysis going wrong as it ends up incorrectly skipping over the stp
insn when analysing subsequent load pair candidates.

Bootstrapped/regtested as a series with/without the passes enabled on
aarch64-linux-gnu (1/4 also tested independently and no regressions).

OK for trunk?

Thanks,
Alex

Alex Coplan (4):
  rtl-ssa: Run finalize_new_accesses forwards [PR113070]
  rtl-ssa: Support for creating new uses [PR113070]
  rtl-ssa: Ensure new defs get inserted [PR113070]
  aarch64: Fix up uses of mem following stp insert [PR113070]

 gcc/config/aarch64/aarch64-ldp-fusion.cc | 248 ++-
 gcc/rtl-ssa.h|   1 +
 gcc/rtl-ssa/accesses.cc  |  10 +
 gcc/rtl-ssa/changes.cc   |  71 +--
 gcc/rtl-ssa/functions.h  |  11 +-
 5 files changed, 269 insertions(+), 72 deletions(-)



[PATCH 1/4] rtl-ssa: Run finalize_new_accesses forwards [PR113070]

2024-01-13 Thread Alex Coplan
The next patch in this series exposes an interface for creating new uses
in RTL-SSA.  The intent is that new user-created uses can consume new
user-created defs in the same change group.  This is so that we can
correctly update uses of memory when inserting a new store pair insn in
the aarch64 load/store pair fusion pass (the affected uses need to
consume the new store pair insn).

As it stands, finalize_new_accesses is called as part of the backwards
insn placement loop within change_insns, but if we want new uses to be
able to depend on new defs in the same change group, we need
finalize_new_accesses to be called on earlier insns first.  This is so
that when we process temporary uses and turn them into permanent uses,
we can follow the last_def link on the temporary def to ensure we end up
with a permanent use consuming a permanent def.

Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?

Thanks,
Alex

gcc/ChangeLog:

PR target/113070
* rtl-ssa/changes.cc (function_info::change_insns): Split out the call
to finalize_new_accesses from the backwards placement loop, run it
forwards in a separate loop.
---
 gcc/rtl-ssa/changes.cc | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/gcc/rtl-ssa/changes.cc b/gcc/rtl-ssa/changes.cc
index 2fac45ae885..e538b637848 100644
--- a/gcc/rtl-ssa/changes.cc
+++ b/gcc/rtl-ssa/changes.cc
@@ -775,15 +775,26 @@ function_info::change_insns (array_slice changes)
 	  placeholder = add_placeholder_after (after);
 	  following_insn = placeholder;
 	}
-
-	  // Finalize the new list of accesses for the change.  Don't install
-	  // them yet, so that we still have access to the old lists below.
-	  finalize_new_accesses (change,
- placeholder ? placeholder : insn);
 	}
   placeholders[i] = placeholder;
 }
 
+  // Finalize the new list of accesses for each change.  Don't install them yet,
+  // so that we still have access to the old lists below.
+  //
+  // Note that we do this forwards instead of in the backwards loop above so
+  // that any new defs being inserted are processed before new uses of those
+  // defs, so that the (initially) temporary uses referring to temporary defs
+  // can be easily updated to become permanent uses referring to permanent defs.
+  for (unsigned i = 0; i < changes.size (); i++)
+{
+  insn_change &change = *changes[i];
+  insn_info *placeholder = placeholders[i];
+  if (!change.is_deletion ())
+	finalize_new_accesses (change,
+			   placeholder ? placeholder : change.insn ());
+}
+
   // Remove all definitions that are no longer needed.  After the above,
   // the only uses of such definitions should be dead phis and now-redundant
   // live-out uses.


[PATCH 2/4] rtl-ssa: Support for creating new uses [PR113070]

2024-01-13 Thread Alex Coplan
This exposes an interface for users to create new uses in RTL-SSA.
This is needed for updating uses after inserting a new store pair insn
in the aarch64 load/store pair fusion pass.

gcc/ChangeLog:

PR target/113070
* rtl-ssa/accesses.cc (function_info::create_use): New.
* rtl-ssa/changes.cc (function_info::finalize_new_accesses):
Handle temporary uses, ensure new uses end up referring to
permanent defs.
* rtl-ssa/functions.h (function_info::create_use): Declare.
---
 gcc/rtl-ssa/accesses.cc | 10 ++
 gcc/rtl-ssa/changes.cc  | 24 +++-
 gcc/rtl-ssa/functions.h |  5 +
 3 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/gcc/rtl-ssa/accesses.cc b/gcc/rtl-ssa/accesses.cc
index ce4a8b8dc00..3f1304fc5bf 100644
--- a/gcc/rtl-ssa/accesses.cc
+++ b/gcc/rtl-ssa/accesses.cc
@@ -1466,6 +1466,16 @@ function_info::create_set (obstack_watermark &watermark,
   return set;
 }
 
+use_info *
+function_info::create_use (obstack_watermark &watermark,
+			   insn_info *insn,
+			   set_info *set)
+{
+  auto use = change_alloc (watermark, insn, set->resource (), set);
+  use->m_is_temp = true;
+  return use;
+}
+
 // Return true if ACCESS1 can represent ACCESS2 and if ACCESS2 can
 // represent ACCESS1.
 static bool
diff --git a/gcc/rtl-ssa/changes.cc b/gcc/rtl-ssa/changes.cc
index e538b637848..ce51d6ccd8d 100644
--- a/gcc/rtl-ssa/changes.cc
+++ b/gcc/rtl-ssa/changes.cc
@@ -538,7 +538,9 @@ function_info::finalize_new_accesses (insn_change &change, insn_info *pos)
   unsigned int i = 0;
   for (use_info *use : change.new_uses)
 {
-  if (!use->m_has_been_superceded)
+  if (use->m_is_temp)
+	use->m_has_been_superceded = true;
+  else if (!use->m_has_been_superceded)
 	{
 	  use = allocate_temp (insn, use->resource (), use->def ());
 	  use->m_has_been_superceded = true;
@@ -609,15 +611,27 @@ function_info::finalize_new_accesses (insn_change &change, insn_info *pos)
 	  m_temp_uses[i] = use = allocate (*use);
 	  use->m_is_temp = false;
 	  set_info *def = use->def ();
-	  // Handle cases in which the value was previously not used
-	  // within the block.
-	  if (def && def->m_is_temp)
+	  if (!def || !def->m_is_temp)
+	continue;
+
+	  if (auto phi = dyn_cast (def))
 	{
-	  phi_info *phi = as_a (def);
+	  // Handle cases in which the value was previously not used
+	  // within the block.
 	  gcc_assert (phi->is_degenerate ());
 	  phi = create_degenerate_phi (phi->ebb (), phi->input_value (0));
 	  use->set_def (phi);
 	}
+	  else
+	{
+	  // The temporary def may also be a set added with this change, in
+	  // which case the permanent set is stored in the last_def link,
+	  // and we need to update the use to refer to the permanent set.
+	  gcc_assert (is_a (def));
+	  auto perm_set = as_a (def->last_def ());
+	  gcc_assert (!perm_set->is_temporary ());
+	  use->set_def (perm_set);
+	}
 	}
 }
 
diff --git a/gcc/rtl-ssa/functions.h b/gcc/rtl-ssa/functions.h
index 58d0b50ea83..962180e27d6 100644
--- a/gcc/rtl-ssa/functions.h
+++ b/gcc/rtl-ssa/functions.h
@@ -73,6 +73,11 @@ public:
 			insn_info *insn,
 			resource_info resource);
 
+  // Create a temporary use.
+  use_info *create_use (obstack_watermark &watermark,
+			insn_info *insn,
+			set_info *set);
+
   // Create a temporary insn with code INSN_CODE and pattern PAT.
   insn_info *create_insn (obstack_watermark &watermark,
 			  rtx_code insn_code,


[PATCH 3/4] rtl-ssa: Ensure new defs get inserted [PR113070]

2024-01-13 Thread Alex Coplan
In r14-5820-ga49befbd2c783e751dc2110b544fe540eb7e33eb I added support to
RTL-SSA for inserting new insns, which included support for users
creating new defs.

However, I missed that apply_changes_to_insn needed updating to ensure
that the new defs actually got inserted into the main def chain.  This
meant that when the aarch64 ldp/stp pass inserted a new stp insn, the
stp would just get skipped over during subsequent alias analysis, as its
def never got inserted into the memory def chain.  This (unsurprisingly)
led to wrong code.

This patch fixes the issue by ensuring new user-created defs get
inserted.  I would have preferred to have used a flag internal to the
defs instead of a separate data structure to keep track of them, but since
machine_mode increased to 16 bits we're already at 64 bits in access_info,
and we can't really reuse m_is_temp as the logic in finalize_new_accesses
requires it to get cleared.

Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?

Thanks,
Alex

gcc/ChangeLog:

PR target/113070
* rtl-ssa.h: Include hash-set.h.
* rtl-ssa/changes.cc (function_info::finalize_new_accesses): Add
new_sets parameter and use it to keep track of new user-created sets.
(function_info::apply_changes_to_insn): Also call add_def on new sets.
(function_info::change_insns): Add hash_set to keep track of new
user-created defs.  Plumb it through.
* rtl-ssa/functions.h: Add hash_set parameter to finalize_new_accesses 
and
apply_changes_to_insn.
---
 gcc/rtl-ssa.h   |  1 +
 gcc/rtl-ssa/changes.cc  | 28 +---
 gcc/rtl-ssa/functions.h |  6 --
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/gcc/rtl-ssa.h b/gcc/rtl-ssa.h
index f0cf656f5ac..17337639ae8 100644
--- a/gcc/rtl-ssa.h
+++ b/gcc/rtl-ssa.h
@@ -50,6 +50,7 @@
 #include "mux-utils.h"
 #include "rtlanal.h"
 #include "cfgbuild.h"
+#include "hash-set.h"
 
 // Provides the global crtl->ssa.
 #include "memmodel.h"
diff --git a/gcc/rtl-ssa/changes.cc b/gcc/rtl-ssa/changes.cc
index ce51d6ccd8d..6119ec3535b 100644
--- a/gcc/rtl-ssa/changes.cc
+++ b/gcc/rtl-ssa/changes.cc
@@ -429,7 +429,8 @@ update_insn_in_place (insn_change &change)
 // POS gives the final position of INSN, which hasn't yet been moved into
 // place.
 void
-function_info::finalize_new_accesses (insn_change &change, insn_info *pos)
+function_info::finalize_new_accesses (insn_change &change, insn_info *pos,
+  hash_set &new_sets)
 {
   insn_info *insn = change.insn ();
 
@@ -465,6 +466,12 @@ function_info::finalize_new_accesses (insn_change &change, insn_info *pos)
 		// later in case we see a second write to the same resource.
 		def_info *perm_def = allocate (change.insn (),
 			 def->resource ());
+
+		// Keep track of the new set so we remember to add it to the
+		// def chain later.
+		if (new_sets.add (perm_def))
+		  gcc_unreachable (); // We shouldn't see duplicates here.
+
 		def->set_last_def (perm_def);
 		def = perm_def;
 	  }
@@ -647,7 +654,8 @@ function_info::finalize_new_accesses (insn_change &change, insn_info *pos)
 // Copy information from CHANGE to its underlying insn_info, given that
 // the insn_info has already been placed appropriately.
 void
-function_info::apply_changes_to_insn (insn_change &change)
+function_info::apply_changes_to_insn (insn_change &change,
+  hash_set &new_sets)
 {
   insn_info *insn = change.insn ();
   if (change.is_deletion ())
@@ -659,10 +667,11 @@ function_info::apply_changes_to_insn (insn_change &change)
   // Copy the cost.
   insn->set_cost (change.new_cost);
 
-  // Add all clobbers.  Sets and call clobbers never move relative to
-  // other definitions, so are OK as-is.
+  // Add all clobbers and newly-created sets.  Existing sets and call
+  // clobbers never move relative to other definitions, so are OK as-is.
   for (def_info *def : change.new_defs)
-if (is_a (def) && !def->is_call_clobber ())
+if ((is_a (def) && !def->is_call_clobber ())
+	|| (is_a (def) && new_sets.contains (def)))
   add_def (def);
 
   // Add all uses, now that their position is final.
@@ -793,6 +802,10 @@ function_info::change_insns (array_slice changes)
   placeholders[i] = placeholder;
 }
 
+  // We need to keep track of newly-added sets as these need adding to
+  // the def chain later.
+  hash_set new_sets;
+
   // Finalize the new list of accesses for each change.  Don't install them yet,
   // so that we still have access to the old lists below.
   //
@@ -806,7 +819,8 @@ function_info::change_insns (array_slice changes)
   insn_info *placeholder = placeholders[i];
   if (!change.is_deletion ())
 	finalize_new_accesses (change,
-			   placeholder ? placeholder : change.insn ());
+			   placeholder ? placeholder : change.insn (),
+			   new_sets);
 }
 
   // Remove all definitions that are no longer needed.  After the above,
@@ -861,7 +875,7 @@ function_info::chan

[PATCH 4/4] aarch64: Fix up uses of mem following stp insert [PR113070]

2024-01-13 Thread Alex Coplan
As the PR shows (specifically #c7) we are missing updating uses of mem
when inserting an stp in the aarch64 load/store pair fusion pass.  This
patch fixes that.

RTL-SSA has a simple view of memory and by default doesn't allow stores
to be re-ordered w.r.t. other stores.  In the ldp fusion pass, we do our
own alias analysis and so can re-order stores over other accesses when
we deem this is safe.  If neither store can be re-purposed (moved into
the required position to form the stp while respecting the RTL-SSA
constraints), then we turn both the candidate stores into "tombstone"
insns (logically delete them) and insert a new stp insn.

As it stands, we implement the insert case separately (after dealing
with the candidate stores) in fuse_pair by inserting into the middle of
the vector of changes.  This is OK when we only have to insert one
change, but with this fix we would need to insert the change for the new
stp plus multiple changes to fix up uses of mem (note the number of
fix-ups is naturally bounded by the alias limit param to prevent
quadratic behaviour).  If we kept the code structured as is and inserted
into the middle of the vector, that would lead to repeated moving of
elements in the vector which seems inefficient.  The structure of the
code would also be a little unwieldy.

To improve on that situation, this patch introduces a helper class,
stp_change_builder, which implements a state machine that helps to build
the required changes directly in program order.  That state machine is
reponsible for deciding what changes need to be made in what order, and
the code in fuse_pair then simply follows those steps.

Together with the fix in the previous patch for installing new defs
correctly in RTL-SSA, this fixes PR113070.

We take the opportunity to rename the function decide_stp_strategy to
try_repurpose_store, as that seems more descriptive of what it actually
does, since stp_change_builder is now responsible for the overall change
strategy.

Bootstrapped/regtested as a series with/without the passes enabled on
aarch64-linux-gnu, OK for trunk?

Thanks,
Alex

gcc/ChangeLog:

PR target/113070
* config/aarch64/aarch64-ldp-fusion.cc (struct stp_change_builder): New.
(decide_stp_strategy): Reanme to ...
(try_repurpose_store): ... this.
(ldp_bb_info::fuse_pair): Refactor to use stp_change_builder to
construct stp changes.  Fix up uses when inserting new stp insns.
---
 gcc/config/aarch64/aarch64-ldp-fusion.cc | 248 ++-
 1 file changed, 194 insertions(+), 54 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc b/gcc/config/aarch64/aarch64-ldp-fusion.cc
index 689a8c884bd..703cfb1228c 100644
--- a/gcc/config/aarch64/aarch64-ldp-fusion.cc
+++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc
@@ -844,11 +844,138 @@ def_upwards_move_range (def_info *def)
   return range;
 }
 
+// Class that implements a state machine for building the changes needed to form
+// a store pair instruction.  This allows us to easily build the changes in
+// program order, as required by rtl-ssa.
+struct stp_change_builder
+{
+  enum class state
+  {
+FIRST,
+INSERT,
+FIXUP_USE,
+LAST,
+DONE
+  };
+
+  enum class action
+  {
+TOMBSTONE,
+CHANGE,
+INSERT,
+FIXUP_USE
+  };
+
+  struct change
+  {
+action type;
+insn_info *insn;
+  };
+
+  bool done () const { return m_state == state::DONE; }
+
+  stp_change_builder (insn_info *insns[2],
+		  insn_info *repurpose,
+		  insn_info *dest)
+: m_state (state::FIRST), m_insns { insns[0], insns[1] },
+  m_repurpose (repurpose), m_dest (dest), m_use (nullptr) {}
+
+  change get_change () const
+  {
+switch (m_state)
+  {
+  case state::FIRST:
+	return {
+	  m_insns[0] == m_repurpose ? action::CHANGE : action::TOMBSTONE,
+	  m_insns[0]
+	};
+  case state::LAST:
+	return {
+	  m_insns[1] == m_repurpose ? action::CHANGE : action::TOMBSTONE,
+	  m_insns[1]
+	};
+  case state::INSERT:
+	return { action::INSERT, m_dest };
+  case state::FIXUP_USE:
+	return { action::FIXUP_USE, m_use->insn () };
+  case state::DONE:
+	break;
+  }
+
+gcc_unreachable ();
+  }
+
+  // Transition to the next state.
+  void advance ()
+  {
+switch (m_state)
+  {
+  case state::FIRST:
+	if (m_repurpose)
+	  m_state = state::LAST;
+	else
+	  m_state = state::INSERT;
+	break;
+  case state::INSERT:
+  {
+	def_info *def = memory_access (m_insns[0]->defs ());
+	while (*def->next_def ()->insn () <= *m_dest)
+	  def = def->next_def ();
+
+	// Now we know DEF feeds the insertion point for the new stp.
+	// Look for any uses of DEF that will consume the new stp.
+	gcc_assert (*def->insn () <= *m_dest
+		&& *def->next_def ()->insn () > *m_dest);
+
+	if (auto set = dyn_cast (def))
+	  for (auto use : set->nondebug_insn_uses ())
+	if (*use->insn () > *m_dest)
+	  {
+		m_use = use;
+		break;
+	  }
+
+	if (m_use)
+	  m_state = st

[committed] hppa64: Fix fmt_f_default_field_width_3.f90 and fmt_g_default_field_width_3.f90

2024-01-13 Thread John David Anglin
Tested on hppa64-hp-hpux11.11.  Committed to trunk.

Dave
---

hppa64: Fix fmt_f_default_field_width_3.f90 and fmt_g_default_field_width_3.f90

The hppa*64*-*-hpux* target is not included in the set of fortran_real_16
targets because it doesn't have cosl.  However, these tests don't need
cosl, etc.

2024-01-13  John David Anglin  

gcc/testsuite/ChangeLog:

* gfortran.dg/fmt_f_default_field_width_3.f90: Add hppa*64*-*-hpux*
to real_16 dg-error targets.
* gfortran.dg/fmt_g_default_field_width_3.f90: Likewise.

diff --git a/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90 
b/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90
index 3e7d8f64d43..46f271e0c60 100644
--- a/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90
+++ b/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90
@@ -30,6 +30,6 @@ program test
 
 #ifdef __GFC_REAL_16__
 real_16 = 4.18
-write(buffer, fmt) ':',real_16,':' ! { dg-error "Nonnegative width 
required"  "" { target fortran_real_16 } }
+write(buffer, fmt) ':',real_16,':' ! { dg-error "Nonnegative width 
required"  "" { target { fortran_real_16 || { hppa*64*-*-hpux* } } } }
 #endif
 end
diff --git a/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_3.f90 
b/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_3.f90
index 95a05981941..22fe1a35d65 100644
--- a/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_3.f90
+++ b/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_3.f90
@@ -33,6 +33,6 @@ program test
 
 #ifdef __GFC_REAL_16__
 real_16 = 4.18
-write(buffer, fmt) ':',real_16,':' ! { dg-error "Positive width required" 
"" { target fortran_real_16 } }
+write(buffer, fmt) ':',real_16,':' ! { dg-error "Positive width required" 
"" { target { fortran_real_16 || { hppa*64*-*-hpux* } } } }
 #endif
 end


signature.asc
Description: PGP signature


[PATCH] testsuite: Turn errors back into warnings in arm/acle/cde-mve-error-2.c

2024-01-13 Thread Thiago Jung Bauermann
Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
permerrors") the test fails with errors such as:

  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 32)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 33)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 34)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 35)
⋮
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 118 (test for 
warnings, line 117)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
119)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 120 (test for 
warnings, line 119)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
121)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 122 (test for 
warnings, line 121)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
123)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 124 (test for 
warnings, line 123)
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
125)
⋮
  FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0  (test for excess errors)

There's a total of 1016 errors.  Here's a sample of the excess errors:

  Excess errors:
  /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:117:31: 
error: passing argument 2 of '__builtin_arm_vcx1qv16qi' makes integer from 
pointer without a cast [-Wint-conversion]
  /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:119:3: 
error: passing argument 3 of '__builtin_arm_vcx1qav16qi' makes integer from 
pointer without a cast [-Wint-conversion]
  /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:121:3: 
error: passing argument 3 of '__builtin_arm_vcx2qv16qi' makes integer from 
pointer without a cast [-Wint-conversion]
  /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:123:3: 
error: passing argument 3 of '__builtin_arm_vcx2qv16qi' makes integer from 
pointer without a cast [-Wint-conversion]

The test expects these messages to be warnings, not errors.  My first try
was to change it to expect them as errors instead.  This didn't work, IIUC
because the error prevents the compiler from continuing processing the file
and thus other errors which are expected by the test don't get emitted.

Therefore, add -fpermissive so that the test behaves as it did previously.
Because of the additional line in the header, I had to adjust the line
numbers of the expected warnings.

Tested on armv8l-linux-gnueabihf.

gcc/testsuite/ChangeLog:
* gcc.target/arm/acle/cde-mve-error-2.c: Add -fpermissive.
---
 .../gcc.target/arm/acle/cde-mve-error-2.c | 63 ++-
 1 file changed, 32 insertions(+), 31 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c 
b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
index 5b7774825442..da283a06a54d 100644
--- a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
+++ b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
@@ -2,6 +2,7 @@
 
 /* { dg-do assemble } */
 /* { dg-require-effective-target arm_v8_1m_main_cde_mve_fp_ok } */
+/* { dg-options "-fpermissive" } */
 /* { dg-add-options arm_v8_1m_main_cde_mve_fp } */
 
 /* The error checking files are split since there are three kinds of
@@ -115,73 +116,73 @@ uint8x16_t test_bad_immediates (uint8x16_t n, uint8x16_t 
m, int someval,
 
   /* `imm' is of wrong type.  */
   accum += __arm_vcx1q_u8 (0, "");/* { dg-error {argument 
2 to '__builtin_arm_vcx1qv16qi' must be a constant immediate in range 
\[0-4095\]} } */
-  /* { dg-warning {passing argument 2 of '__builtin_arm_vcx1qv16qi' makes 
integer from pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 
117 } */
+  /* { dg-warning {passing argument 2 of '__builtin_arm_vcx1qv16qi' makes 
integer from pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 
118 } */
   accum += __arm_vcx1qa (0, accum, "");   /* { dg-error {argument 
3 to '__builtin_arm_vcx1qav16qi' must be a constant immediate in range 
\[0-4095\]} } */
-  /* { dg-warning {passing argument 3 of '__builtin_arm_vcx1qav16qi' makes 
integer from pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 
119 } */
+  /* { dg-warning {passing argument 3 of '__builtin_arm_vcx1qav16qi' makes 
integer from pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 
120 } */
   accum += __arm_vcx2q (0, n, "");/* { dg-error {argument 
3 to '__builtin_arm_vcx2qv16qi' must be a constant immediate in range 
\[0-127\]} } */
-  /* { dg-warning {passing argument 3 of '__builtin_arm_vcx2qv16qi' makes 
integer from pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 
121 } */
+  /* { dg-warning {passing argument 3 of '__builtin_arm_vcx2qv16qi' makes 
integer from pointer without a cast \[-Wint-conversion\]} "" { ta

[PATCH] Fortran: intrinsic ISHFTC and missing optional argument SIZE [PR67277]

2024-01-13 Thread Harald Anlauf
Dear all,

the testcase given in PR67277 actually consists of two separate issues:

(1) passing an optional dummy argument to an elemental (intrinsic) procedure

(2) a missing optional argument for SIZE to the ISHFTC intrinsic
shall be equivalent to using BIT_SIZE(I).

I've created a separate PR113377 for (1), as this looks like a more
general issue with the scalarizer.

The attached, rather simple and obvious patch thus fixes (2).
Besides testing that the patch works as advertised, the testcase
also contains variations that need fixing of PR113377 before they
can be uncommented.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

As I consider the patch safe, I'd like to backport to 13-branch later.

Thanks,
Harald

P.S.: if someone out there feels familiar with the scalarizer,
a look at PR113377 is appreciated.

From 20da56165273c8814b3c53e6d71549ba6a37e0cd Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 13 Jan 2024 22:00:21 +0100
Subject: [PATCH] Fortran: intrinsic ISHFTC and missing optional argument SIZE
 [PR67277]

gcc/fortran/ChangeLog:

	PR fortran/67277
	* trans-intrinsic.cc (gfc_conv_intrinsic_ishftc): Handle optional
	dummy argument for SIZE passed to ISHFTC.  Set default value to
	BIT_SIZE(I) when missing.

gcc/testsuite/ChangeLog:

	PR fortran/67277
	* gfortran.dg/ishftc_optional_size_1.f90: New test.
---
 gcc/fortran/trans-intrinsic.cc| 14 +++
 .../gfortran.dg/ishftc_optional_size_1.f90| 97 +++
 2 files changed, 111 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/ishftc_optional_size_1.f90

diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 74139262657..0468dfae2b1 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -6863,9 +6863,23 @@ gfc_conv_intrinsic_ishftc (gfc_se * se, gfc_expr * expr)

   if (num_args == 3)
 {
+  gfc_expr *size = expr->value.function.actual->next->next->expr;
+
   /* Use a library function for the 3 parameter version.  */
   tree int4type = gfc_get_int_type (4);

+  /* Treat optional SIZE argument when it is passed as an optional
+	 dummy.  If SIZE is absent, the default value is BIT_SIZE(I).  */
+  if (size->expr_type == EXPR_VARIABLE
+	  && size->symtree->n.sym->attr.dummy
+	  && size->symtree->n.sym->attr.optional)
+	{
+	  tree type_of_size = TREE_TYPE (args[2]);
+	  args[2] = build3_loc (input_location, COND_EXPR, type_of_size,
+gfc_conv_expr_present (size->symtree->n.sym),
+args[2], fold_convert (type_of_size, nbits));
+	}
+
   /* We convert the first argument to at least 4 bytes, and
 	 convert back afterwards.  This removes the need for library
 	 functions for all argument sizes, and function will be
diff --git a/gcc/testsuite/gfortran.dg/ishftc_optional_size_1.f90 b/gcc/testsuite/gfortran.dg/ishftc_optional_size_1.f90
new file mode 100644
index 000..1ccf4b38caa
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/ishftc_optional_size_1.f90
@@ -0,0 +1,97 @@
+! { dg-do run }
+!
+! PR fortran/67277 - ISHFTC and missing optional argument SIZE
+
+module m
+  implicit none
+contains
+  ! Optional argument passed by reference
+  elemental function ishftc4_ref (i, shift, size_) result(r)
+integer(4), intent(in)   :: i
+integer,intent(in)   :: shift
+integer,intent(in), optional :: size_
+integer  :: r
+r = ishftc (i, shift=shift, size=size_)
+  end
+
+  elemental function ishftc1_ref (i, shift, size_) result(r)
+integer(1), intent(in)   :: i
+integer,intent(in)   :: shift
+integer(1), intent(in), optional :: size_
+integer(1)   :: r
+r = ishftc (i, shift=shift, size=size_)
+  end
+
+  ! Array valued argument i
+  function ishftc4_ref_4 (i, shift, size_) result(r)
+integer(4), intent(in)   :: i(4)
+integer,intent(in)   :: shift
+integer,intent(in), optional :: size_
+integer  :: r(size(i))
+r = ishftc (i, shift=shift, size=size_)
+  end
+
+  ! Optional argument passed by value
+  elemental function ishftc4_val (i, shift, size_) result(r)
+integer(4), intent(in)   :: i
+integer,intent(in)   :: shift
+integer,value,  optional :: size_
+integer  :: r
+r = ishftc (i, shift=shift, size=size_)
+  end
+
+  elemental function ishftc1_val (i, shift, size_) result(r)
+integer(1), intent(in)   :: i
+integer,intent(in)   :: shift
+integer(1), value,  optional :: size_
+integer(1)   :: r
+r = ishftc (i, shift=shift, size=size_)
+  end
+
+  ! Array valued argument i
+  function ishftc4_val_4 (i, shift, size_) result(r)
+integer(4), intent(in)   :: i(4)
+integer,intent(in)   :: shift
+integer,value,  optional :: size_
+integer  ::

Re: [PATCH] Fortran: intrinsic ISHFTC and missing optional argument SIZE [PR67277]

2024-01-13 Thread Steve Kargl
On Sat, Jan 13, 2024 at 10:12:42PM +0100, Harald Anlauf wrote:
> 
> (2) a missing optional argument for SIZE to the ISHFTC intrinsic
> shall be equivalent to using BIT_SIZE(I).
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> 
> As I consider the patch safe, I'd like to backport to 13-branch later.
> 

OK for both trunk and a backport as time permits.

-- 
Steve


[PATCH] libcpp: Support extended characters for #pragma {push, pop}_macro [PR109704]

2024-01-13 Thread Lewis Hyatt
Hello-

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704

The below patch fixes the issue noted in the PR that extended characters
cannot appear in the identifier passed to a #pragma push_macro or #pragma
pop_macro. Bootstrap + regtest all languages on x86-64 Linux. Is it OK for
GCC 13 please?

I know we just entered stage 4, however I feel this is kinda like an old
regression, given that the issue was not apparent until support for UCNs and
UTF-8 in identifiers got added. FWIW, it would be nice if it makes it into
GCC 13, because AFAIK all other UTF-8-related bugs are fixed in this
release. (The other major one was for extended characters in a user-defined
literal, that was fixed by r14-2629).

Speaking of just entering stage 4. I do have 4 really short patches sent
over the past several months that never got any response. Is there any
chance someone may have a few minutes to look at them please? They are
really just like 1-3 line fixes for PRs.

libcpp (pinged once recently):
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640386.html

diagnostics (pinged for 3rd time last week):
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html

c-family/PCH (pinged a month ago):
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639467.html

Thanks!

-Lewis

-- >8 --

The implementation of #pragma push_macro and #pragma pop_macro has to date
made use of an ad-hoc function, _cpp_lex_identifier(), which lexes an
identifier out of a string. When support was added for extended characters
in identifiers ($, UCNs, or UTF-8), that support was added only for the
"normal" way of lexing identifiers out of a cpp_buffer (_cpp_lex_direct) and
not for the ad-hoc way. Consequently, extended identifiers are not usable
with these pragmas.

The logic for lexing identifiers has become more complicated than it was
when _cpp_lex_identifier() was written -- it now handles things like \N{}
escapes in C++, for instance -- and it no longer seems practical to maintain
a redundant code path for lexing identifiers. Address the issue by changing
the implementation of #pragma {push,pop}_macro to lex identifiers in the
expected way, i.e. by pushing a cpp_buffer and lexing the identifier from
there.

The existing implementation has some quirks because of the ad-hoc parsing
logic. For example:

 #pragma push_macro("X ")
 ...
 #pragma pop_macro("X")

will not restore macro X (note the extra space in the first string). However:

 #pragma push_macro("X ")
 ...
 #pragma pop_macro("X ")

actually does sucessfully restore "X". This is because the key for looking
up the saved macro on the push stack is the original string passed, so the
string passed to pop_macro needs to match it exactly. It is not that easy to
reproduce this logic in the world of extended characters, given that for
example it should be valid to pass a UCN to push_macro, and the
corresponding UTF-8 to pop_macro. Given that this aspect of the existing
behavior seems unintentional and has no tests (and does not match other
implementations), I opted to make the new logic more straightforward. The
string passed needs to lex to one token, which must be a valid identifier,
or else no action is taken and no error is generated. Any diagnostics
encountered during lexing (e.g., due to a UTF-8 character not permitted to
appear in an identifier) are also suppressed.

It could be nice (for GCC 15) to also add a warning if a pop_macro does not
match a previous push_macro.

libcpp/ChangeLog:

PR preprocessor/109704
* include/cpplib.h (class cpp_auto_suppress_diagnostics): New class.
* errors.cc
(cpp_auto_suppress_diagnostics::cpp_auto_suppress_diagnostics): New
function.
(cpp_auto_suppress_diagnostics::~cpp_auto_suppress_diagnostics): New
function.
* charset.cc (noop_diagnostic_cb): Remove.
(cpp_interpret_string_ranges): Refactor diagnostic suppression logic
into new class cpp_auto_suppress_diagnostics.
(count_source_chars): Likewise.
* directives.cc (cpp_pop_definition): Add cpp_hashnode argument.
(lex_identifier_from_string): New static helper function.
(push_pop_macro_common): Refactor common logic from
do_pragma_push_macro and do_pragma_pop_macro; use
lex_identifier_from_string instead of _cpp_lex_identifier.
(do_pragma_push_macro): Reimplement using push_pop_macro_common.
(do_pragma_pop_macro): Likewise.
* internal.h (_cpp_lex_identifier): Remove.
* lex.cc (lex_identifier_intern): Remove.
(_cpp_lex_identifier): Remove.

gcc/testsuite/ChangeLog:

PR preprocessor/109704
* c-c++-common/cpp/pragma-push-pop-utf8.c: New test.
* g++.dg/pch/pushpop-2.C: New test.
* g++.dg/pch/pushpop-2.Hs: New test.
* gcc.dg/pch/pushpop-2.c: New test.
* gcc.dg/pch/pushpop-2.hs: New test.
---
 libcpp/charset.cc   

[PATCH] libsupc++: Fix UB terminating on foreign exception

2024-01-13 Thread Julia DeMille
Currently, when std::terminate() is called with a foreign exception
active, since nothing in the path checks whether the exception matches
the `GNUCC++\0` personality, a foreign exception can go into the verbose
terminate handler, and get treated as though it were a C++ exception.

Reflection is attempted, and boom. UB. This patch should eliminate that
UB.

Signed-off-by: Julia DeMille 
---
 libstdc++-v3/ChangeLog   |  9 +
 libstdc++-v3/libsupc++/eh_type.cc| 11 +++
 libstdc++-v3/libsupc++/vterminate.cc | 25 -
 3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 36257cc4427..bfef0ed8ef1 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,12 @@
+2024-01-13  Julia DeMille  
+   * libsupc++/eh_type.cc (__cxa_current_exception_type):
+   Return NULL if the current exception is not the `GNUCC++\0`
+   personality.
+   * libsupc++/vterminate.cc:
+   Check for both exception header and exception type. If there
+   is an exception header, but no exception type, state in termination
+   message that a foreign exception was active.
+
 2024-01-13  Jonathan Wakely  
 
PR libstdc++/107466
diff --git a/libstdc++-v3/libsupc++/eh_type.cc 
b/libstdc++-v3/libsupc++/eh_type.cc
index 03c677b7e13..e0824eab4d4 100644
--- a/libstdc++-v3/libsupc++/eh_type.cc
+++ b/libstdc++-v3/libsupc++/eh_type.cc
@@ -36,9 +36,20 @@ extern "C"
 std::type_info *__cxa_current_exception_type () _GLIBCXX_NOTHROW
 {
   __cxa_eh_globals *globals = __cxa_get_globals ();
+
+  if (!globals)
+return 0;
+
   __cxa_exception *header = globals->caughtExceptions;
+
   if (header)
 {
+  // It is UB to try and inspect an exception that isn't ours.
+  // This extends to attempting to perform run-time reflection, as the ABI
+  // is unknown.
+  if (!__is_gxx_exception_class (header->unwindHeader.exception_class))
+return 0;
+
   if (__is_dependent_exception (header->unwindHeader.exception_class))
 {
   __cxa_dependent_exception *de =
diff --git a/libstdc++-v3/libsupc++/vterminate.cc 
b/libstdc++-v3/libsupc++/vterminate.cc
index 23deeef5289..f931d951526 100644
--- a/libstdc++-v3/libsupc++/vterminate.cc
+++ b/libstdc++-v3/libsupc++/vterminate.cc
@@ -25,11 +25,12 @@
 #include 
 
 #if _GLIBCXX_HOSTED
-#include 
-#include 
+#include "unwind-cxx.h"
 #include 
+#include 
+#include 
 #include 
-# include 
+#include 
 
 using namespace std;
 using namespace abi;
@@ -51,10 +52,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 terminating = true;
 
+__cxa_eh_globals *globals = __cxa_get_globals ();
+if (!globals)
+  {
+fputs ("terminate called", stderr);
+abort ();
+  }
+
 // Make sure there was an exception; terminate is also called for an
 // attempt to rethrow when there is no suitable exception.
-type_info *t = __cxa_current_exception_type();
-if (t)
+type_info *t = __cxa_current_exception_type ();
+__cxa_exception *header = globals->caughtExceptions;
+
+if (t && header)
   {
// Note that "name" is the mangled name.
char const *name = t->name();
@@ -89,6 +99,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
__catch(...) { }
   }
+else if (header)
+  {
+fputs ("terminate called after a foreign exception was thrown\n",
+   stderr);
+  }
 else
   fputs("terminate called without an active exception\n", stderr);
 
-- 
2.43.0



Re: [PATCH] libsupc++: Fix UB terminating on foreign exception

2024-01-13 Thread Andrew Pinski
On Sat, Jan 13, 2024 at 5:10 PM Julia DeMille  wrote:
>
> Currently, when std::terminate() is called with a foreign exception
> active, since nothing in the path checks whether the exception matches
> the `GNUCC++\0` personality, a foreign exception can go into the verbose
> terminate handler, and get treated as though it were a C++ exception.
>
> Reflection is attempted, and boom. UB. This patch should eliminate that
> UB.

2 things, changelogs go into the email message rather than directly as
part of the patch.,
Second I wonder if you could add a multiple language testcase using
GNU objective-C exceptions as an example.
If not directly adding a testcase there, at least a simple test that
shows the issue outside of the testsuite?

Thanks,
Andrew Pinski

>
> Signed-off-by: Julia DeMille 
> ---
>  libstdc++-v3/ChangeLog   |  9 +
>  libstdc++-v3/libsupc++/eh_type.cc| 11 +++
>  libstdc++-v3/libsupc++/vterminate.cc | 25 -
>  3 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
> index 36257cc4427..bfef0ed8ef1 100644
> --- a/libstdc++-v3/ChangeLog
> +++ b/libstdc++-v3/ChangeLog
> @@ -1,3 +1,12 @@
> +2024-01-13  Julia DeMille  
> +   * libsupc++/eh_type.cc (__cxa_current_exception_type):
> +   Return NULL if the current exception is not the `GNUCC++\0`
> +   personality.
> +   * libsupc++/vterminate.cc:
> +   Check for both exception header and exception type. If there
> +   is an exception header, but no exception type, state in termination
> +   message that a foreign exception was active.
> +
>  2024-01-13  Jonathan Wakely  
>
> PR libstdc++/107466
> diff --git a/libstdc++-v3/libsupc++/eh_type.cc 
> b/libstdc++-v3/libsupc++/eh_type.cc
> index 03c677b7e13..e0824eab4d4 100644
> --- a/libstdc++-v3/libsupc++/eh_type.cc
> +++ b/libstdc++-v3/libsupc++/eh_type.cc
> @@ -36,9 +36,20 @@ extern "C"
>  std::type_info *__cxa_current_exception_type () _GLIBCXX_NOTHROW
>  {
>__cxa_eh_globals *globals = __cxa_get_globals ();
> +
> +  if (!globals)
> +return 0;
> +
>__cxa_exception *header = globals->caughtExceptions;
> +
>if (header)
>  {
> +  // It is UB to try and inspect an exception that isn't ours.
> +  // This extends to attempting to perform run-time reflection, as the 
> ABI
> +  // is unknown.
> +  if (!__is_gxx_exception_class (header->unwindHeader.exception_class))
> +return 0;
> +
>if (__is_dependent_exception (header->unwindHeader.exception_class))
>  {
>__cxa_dependent_exception *de =
> diff --git a/libstdc++-v3/libsupc++/vterminate.cc 
> b/libstdc++-v3/libsupc++/vterminate.cc
> index 23deeef5289..f931d951526 100644
> --- a/libstdc++-v3/libsupc++/vterminate.cc
> +++ b/libstdc++-v3/libsupc++/vterminate.cc
> @@ -25,11 +25,12 @@
>  #include 
>
>  #if _GLIBCXX_HOSTED
> -#include 
> -#include 
> +#include "unwind-cxx.h"
>  #include 
> +#include 
> +#include 
>  #include 
> -# include 
> +#include 
>
>  using namespace std;
>  using namespace abi;
> @@ -51,10 +52,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>}
>  terminating = true;
>
> +__cxa_eh_globals *globals = __cxa_get_globals ();
> +if (!globals)
> +  {
> +fputs ("terminate called", stderr);
> +abort ();
> +  }
> +
>  // Make sure there was an exception; terminate is also called for an
>  // attempt to rethrow when there is no suitable exception.
> -type_info *t = __cxa_current_exception_type();
> -if (t)
> +type_info *t = __cxa_current_exception_type ();
> +__cxa_exception *header = globals->caughtExceptions;
> +
> +if (t && header)
>{
> // Note that "name" is the mangled name.
> char const *name = t->name();
> @@ -89,6 +99,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  #endif
> __catch(...) { }
>}
> +else if (header)
> +  {
> +fputs ("terminate called after a foreign exception was thrown\n",
> +   stderr);
> +  }
>  else
>fputs("terminate called without an active exception\n", stderr);
>
> --
> 2.43.0
>


Re: [PATCH] libsupc++: Fix UB terminating on foreign exception

2024-01-13 Thread Julia DeMille

On 1/13/24 19:17, Andrew Pinski wrote:

2 things, changelogs go into the email message rather than directly as
part of the patch.,


Apologies. I have prepared a revised patch, and will send it when 
applicable.



Second I wonder if you could add a multiple language testcase using
GNU objective-C exceptions as an example.
If not directly adding a testcase there, at least a simple test that
shows the issue outside of the testsuite?


I initially discovered this during experimenting with unwinds from a 
Rust library ("C-unwind" ABI) into a C++ application. I can upload the 
code I used for that.


--
I'm sending this message from my laptop, so I may be on the go. Please 
excuse my brevity.




Re: [PATCH v2]: gcc/doc/extend.texi: Update builtin example for __builtin_FILE, __builtin_LINE __builtin_FUNCTION

2024-01-13 Thread Sandra Loosemore

On 1/10/24 14:28, Jonny Grant wrote:
>
> 2024-01-10  Jonathan Grant  
> gcc/ChangeLog:
>* doc/extend.texi: Update builtin example for __builtin_FILE
>   __builtin_LINE __builtin_FUNCTION.
>
>
>
>>From 66290eb477dd1a99310ad9972c45391c2a87c1c7 Mon Sep 17 00:00:00 2001
> From: Jonathan Grant 
> Date: Wed, 29 Nov 2023 11:02:06 +
> Subject: [PATCH] gcc/doc: Update builtin example for __builtin_FILE
>   __builtin_LINE __builtin_FUNCTION
>
>
> Signed-off-by: Jonathan Grant 
> ---
>   gcc/doc/extend.texi | 14 --
>   1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 1ae589aeb29..f17a4b215de 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -14660,20 +14660,22 @@ to @var{F} or the empty string if the call was not 
made at function

>   scope.
>
>   For example, in the following, each call to function @code{foo} will
> -print a line similar to @code{"file.c:123: foo: message"} with the name
> +print a line similar to @code{"file.c:5: foo: message"} with the name

Please also s/will print/prints/

>   of the file and the line number of the @code{printf} call, the name of
>   the function @code{foo}, followed by the word @code{message}.
>
>   @smallexample
> -const char*
> -function (const char *func = __builtin_FUNCTION ())
> +#include 
> +
> +void foo (void)
>   @{
> -  return func;
> +  printf ("%s:%i: %s: message\n", __builtin_FILE (), __builtin_LINE (), 
__builtin_FUNCTION ());
> +  printf ("%s:%i: %s: message\n", __builtin_FILE (), __builtin_LINE (), 
__builtin_FUNCTION ());


Is this duplicated code a mistake?  As you have it, each call to foo prints 
*two* lines, not "a line".  Maybe you mean to have more than one call to foo 
instead of more than one line printed per call?  If it's intentional, please 
correct the above descriptive text.


Also, I'm pretty sure this line of code is too long to format nicely in the PDF 
manual (it's well over 80 characters).  I'd put a line break after the call to 
__builtin_FILE ().


-Sandra




Re: [PATCH] libsupc++: Fix UB terminating on foreign exception

2024-01-13 Thread Jonathan Wakely
On Sun, 14 Jan 2024, 01:36 Julia DeMille,  wrote:

> On 1/13/24 19:17, Andrew Pinski wrote:
> > 2 things, changelogs go into the email message rather than directly as
> > part of the patch.,
>

The reason for this is that the ChangeLog files are auto-generated from the
git commit messages, not edited by hand. Patches to those files rarely
apply cleanly anyway, because they change so frequently that patches are
stale almost immediately.


> Apologies. I have prepared a revised patch, and will send it when
> applicable.
>

Thanks.


> > Second I wonder if you could add a multiple language testcase using
> > GNU objective-C exceptions as an example.
> > If not directly adding a testcase there, at least a simple test that
> > shows the issue outside of the testsuite?
>
> I initially discovered this during experimenting with unwinds from a
> Rust library ("C-unwind" ABI) into a C++ application. I can upload the
> code I used for that.
>

That would be great thanks. If not obvious, easy instructions for building
the test would be helpful for Rust newbs such as myself!