Re: [PATCH] Document locality partitioning params in invoke.texi

[Richard Biener]

On Tue, Apr 22, 2025 at 10:51 AM Kyrylo Tkachov  wrote:
>
> Hi all,
>
> Filip Kastl pointed out that contrib/check-params-in-docs.py complains
> about params not documented in invoke.texi, so this patch adds the short
> explanation from params.opt for these to the invoke.texi section.
> Thanks for the reminder.
>
> Ok for trunk and GCC 15 branch?

OK.

Richard.

> Kyrill
>
> Signed-off-by: Kyrylo Tkachov 
>
> * invoke.texi (lto-partition-locality-frequency-cutoff,
> lto-partition-locality-size-cutoff, lto-max-locality-partition):
> Document.
>

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 08:28, Rainer Orth  wrote:
>
> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> This patch fixes that.
>
> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>
> Ok for both?

This adds:

+TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
+TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11

For the other linux targets we don't include those in the baselines.

[PATCH] libstdc++: Increase timeouts for format and flat_maps tests

[Tomasz Kamiński]

Test for format parse format string and compile time,
flat_maps ones test all functionality in single test file.

libstdc++-v3/ChangeLog:

* testsuite/23_containers/flat_map/1.cc: Add dg-timeout-factor 2.
* testsuite/23_containers/flat_multimap/1.cc: Likewise.
* testsuite/std/format/ranges/map.cc: Likewise.
* testsuite/std/format/ranges/sequence.cc: Likewise.
* testsuite/std/format/ranges/string.cc: Likewise.
---
This makes the test pass with timeout set for 60s (used for the .gnurc file
that we use for compiler farm). OK for turnk?

 libstdc++-v3/testsuite/23_containers/flat_map/1.cc  | 1 +
 libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc | 1 +
 libstdc++-v3/testsuite/std/format/ranges/map.cc | 1 +
 libstdc++-v3/testsuite/std/format/ranges/sequence.cc| 1 +
 libstdc++-v3/testsuite/std/format/ranges/string.cc  | 1 +
 5 files changed, 5 insertions(+)

diff --git a/libstdc++-v3/testsuite/23_containers/flat_map/1.cc 
b/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
index d9d88c4df6e..4fd33f616f7 100644
--- a/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
+++ b/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++23 } }
+// { dg-timeout-factor 2 }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc 
b/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
index ff180bf1bdf..ea0d4b41e9f 100644
--- a/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
+++ b/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++23 } }
+// { dg-timeout-factor 2 }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/ranges/map.cc 
b/libstdc++-v3/testsuite/std/format/ranges/map.cc
index 34c5ed554b8..1838480e2cf 100644
--- a/libstdc++-v3/testsuite/std/format/ranges/map.cc
+++ b/libstdc++-v3/testsuite/std/format/ranges/map.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++23 } }
+// { dg-timeout-factor 2 }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/ranges/sequence.cc 
b/libstdc++-v3/testsuite/std/format/ranges/sequence.cc
index 61fc68ea252..f05f6ec1e1c 100644
--- a/libstdc++-v3/testsuite/std/format/ranges/sequence.cc
+++ b/libstdc++-v3/testsuite/std/format/ranges/sequence.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++23 } }
+// { dg-timeout-factor 2 }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/ranges/string.cc 
b/libstdc++-v3/testsuite/std/format/ranges/string.cc
index 7f59f59dda3..cf39aa66e07 100644
--- a/libstdc++-v3/testsuite/std/format/ranges/string.cc
+++ b/libstdc++-v3/testsuite/std/format/ranges/string.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++23 } }
+// { dg-timeout-factor 2 }
 
 #include 
 #include 
-- 
2.49.0

Re: [PATCH] [RISC-V]Support -mcpu for Xuantie cpu

[Jeff Law]

On 4/20/25 9:56 AM, Yixuan Chen wrote:

gcc/ChangeLog:

 * config/riscv/riscv-cores.def (RISCV_TUNE): Add xt-c908, xt-c908v, 
xt-c910, xt-c910v2, xt-c920, xt-c920v2.
 (RISCV_CORE): Add xt-c908, xt-c908v, xt-c910, xt-c910v2, xt-c920, 
xt-c920v2
 * config/riscv/riscv.cc: Add xt-c908, xt-c908v, xt-c910, xt-c910v2, 
xt-c920, xt-c920v2
 * doc/invoke.texi:  Add xt-c908, xt-c908v, xt-c910, xt-c910v2, 
xt-c920, xt-c920v2

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/mcpu-xt-c908.c: test -mcpu=xt-c908.
 * gcc.target/riscv/mcpu-xt-c910.c: test -mcpu=xt-c910.
 * gcc.target/riscv/mcpu-xt-c920v2.c: test -mcpu=xt-c920v2.
 * gcc.target/riscv/mcpu-xt-c908v.c: test -mcpu=xt-c908v.
 * gcc.target/riscv/mcpu-xt-c910v2.c: test -mcpu=xt-c910v2.
 * gcc.target/riscv/mcpu-xt-c920.c: test -mcpu=xt-c920.

Support -mcpu=xt-c908, xt-c908v, xt-c910, xt-c910v2, xt-c920, xt-c920v2
for Xuantie series cpu.
ref:https://www.xrvm.cn/community/download?id=4224248662731067392

Thanks.  I've pushed this to the trunk.

Jeff

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Rainer Orth]

Hi Richard,

> On Tue, Apr 22, 2025 at 12:31 PM Sam James  wrote:
>>
>> Jakub Jelinek  writes:
>>
>> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
>> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek  wrote:
>> >> >
>> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> >> > > That's one option, but maybe it's better the other way round: instead 
>> >> > > of
>> >> > > excluding known-bad targets, restrict cobol to known-good ones
>> >> > > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
>> >> > >
>> >> > > I've been using the following for this (should be retested for 
>> >> > > safety).
>> >> >
>> >> > I admit I don't really know what works and what doesn't out of the
>> >> > box now,
>> >> > but your patch looks reasonable to me for 15 branch.
>> >> >
>> >> > Richard, Robert and/or James, do you agree?
>> >>
>> >> I agree to restrict =all to enable cobol only for known-good platform
>> >> triples.
>> >> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to 
>> >> allow
>> >
>> > But libgcobol configure.tgt does it only for the target case.
>> > Much more important right now is the host whitelist case.
>> > The code in the FE is still not sufficiently portable and so even
>> > i686-solaris -> x86_64-linux --enable-languages=all cross just won't
>> > build out
>> > of the box (and even if it would, it wouldn't work properly).
>> > Or x86_64-freebsd -> x86_64-linux might not either.
>> >
>> > So, I think we want Rainer's patch here.
>> >
>>
>> I thought about it further after discussion on IRC and I agree. Rainer's
>> looks good.
>
> OK, let's do that for GCC 15 then, we can add to the whilelist when we figure
> additional known-good cases for 15.2.

what about trunk then?  Right now, cobol still doesn't build there on
Solaris/amd64 because 3 patches are missing:

cobol: Don't require GLOB_BRACE etc. [PR119217]
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680675.html

Still unreviewed.

cobol: Initialize regmatch_t portably [PR119217]
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680676.html

Unclear how exactly to handle this.

cobol: Allow for undefined NAME_MAX [PR119217]
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680682.html

Should go for a variant simply replacing NAME_MAX by its Linux
 value (255) until the whole struct cbl_function_t.name thing
can be resolved.  Already tested on Linux/x86_64 and Solaris/amd64.

libgcobol does build on Solaris (at least on trunk) since

commit a619a128c992b2121a862b8470960ae751d25db6
Author: Rainer Orth 
Date:   Mon Apr 21 15:59:14 2025 +0200

libgcobol: Check for struct tm tm_zone

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH v2] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

[Tomasz Kamiński]

This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.

To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.

As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
 * _CharT is constrained __formatter::__char
 * basic_format_parse_context<_CharT> for parse argument
 * basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.

Furthermore the standard specifies these formatters as delegating to
formatter, charT>, which in turn
delegates to range_formatter. This patch avoids one level of indirection,
and dependency of ranges::ref_view.  This is technically observable if
user specializes formatter> where PD is program defined
container, but I do not think this is the case worth extra indirection.

This patch also moves the formattable and it's dependencies to the formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator>, to struct with type nested typedef
that points to same type, that is forward declared.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in declaration
in bits/formatfwd.h.
* include/std/queue: Include bits/version.h before bits/stl_queue.h.
(formatter, _CharT>)
(formatter, _CharT>): Define.
* include/std/stack: Include bits/version.h before bits/stl_stack.h
(formatter, _CharT>): Define.
* testsuite/std/format/ranges/adaptors.cc: New test.

Reviewed-by: Jonathan Wakely 
Signed-off-by: Tomasz Kamiński 
---
Applied changes to feature test macros. Also in queue/stack files
included bits/version.h before bits/stl_queue.h.

OK for trunk?
 libstdc++-v3/include/bits/formatfwd.h |  78 +
 libstdc++-v3/include/bits/stl_queue.h |  14 ++
 libstdc++-v3/include/bits/stl_stack.h |   9 +
 libstdc++-v3/include/std/format   |  76 +
 libstdc++-v3/include/std/queue|  80 -
 libstdc++-v3/include/std/stack|  48 +-
 .../testsuite/std/format/ranges/adaptors.cc   | 156 ++
 7 files changed, 387 insertions(+), 74 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/adaptors.cc

diff --git a/libstdc++-v3/include/bits/formatfwd.h 
b/libstdc++-v3/include/bits/formatfwd.h
index a6b5ac8c8ce..9ba658b078a 100644
--- a/libstdc++-v3/include/bits/formatfwd.h
+++ b/libstdc++-v3/include/bits/formatfwd.h
@@ -37,6 +37,12 @@
 //  must have been included before this header:
 #ifdef __glibcxx_format // C++ >= 20 && HOSTED
 
+#include 
+#include 
+#if __glibcxx_format_ranges // C++ >= 23 && HOSTED
+#  include   // input_range, range_reference_t
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -50,6 +56,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // [format.formatter], formatter
   template struct formatter;
 
+/// @cond undocumented
 namespace __format
 {
 #ifdef _GLIBCXX_USE_WCHAR_T
@@ -60,9 +67,80 @@ namespace __format
 concept __char = same_as<_CharT, char>;
 #endif
 
+  template>,
+  typename _ParseContext
+= basic_format_parse_context>
+concept __parsable_with
+  = semiregular<_Formatter>
+ && requires (_Formatter __f, _ParseContext __pc)
+{
+  { __f.parse(__pc) } -> same_as;
+};
+
+  template>,
+  typename _ParseContext
+=

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

[Andre Vehreschild]

Hi Jerry, hi Paul,

thanks for the review. Committed as gcc-16-79-g6e3b92848b5 (for the 6 of 5
commit) on mainline. 

Thanks again for the fast review.

Regards,
Andre

On Fri, 18 Apr 2025 18:27:03 -0700
Jerry D  wrote:

> On 4/18/25 9:13 AM, Paul Richard Thomas wrote:
> > Hi Andre,
> > 
> > On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild  > > wrote:
> > 
> > Hi Jerry,
> > 
> > thanks for the review and sorry for the long delay. With publishing
> > the team's
> > patches for gfortran, I also created a pull request for
> > OpenCoarrays. There I
> > was asked to add some testcase with more "beef" in it. I.e.
> > something that
> > really makes use of teams and not only smoke tests it. This
> > unfortunately made
> > me discover some issues, that I needed to fix. The attached patch 6/5
> > addresses these issues. Some of them were as easy as not being able
> > to exit out
> > of change team block or an end team with a label not being parsed
> > correctly and
> > not generated in resulting binary. Others were more subtle, like
> > having to
> > create coarray tokens for association in the change team.
> > 
> > The attached patch addresses all these issues and
> > 
> > bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for
> > mainline?
> > 
> > Btw, do I still merge to master, or am I to wait for the bump to
> > 16th master?
> > 
> > Regards,
> >          Andre
> > 
> > This all looks good to me, except for two tiny nits. It looks as if we 
> > are already on 16-branch :-(
> > 
> > I have been religiously ending ChangeLogs at column 72 since I started 
> > supporting gfortran. If this is still a requirement, I suggest:
> > line 14: s/it is/it's/
> > line 23: carry "are" over to the next line.
> > 
> > OK for mainline and, I would suggest, backporting to 15-branch asap.
> > 
> > Thanks for the patch
> > 
> > Paul
> >   
> 
> Agree, Andre OK for 16, proceed.
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [PATCH] Add a bootstrap-native build config

[Richard Biener]

On Sat, Apr 12, 2025 at 5:09 PM Andi Kleen  wrote:
>
> From: Andi Kleen 
>
> ... that uses -march=native -mtune=native to build a compiler optimized
> for the host.

-march=native implies -mtune=native so I think the latter is redundant.

> config/ChangeLog:
>
> * bootstrap-native.mk: New file.
>
> gcc/ChangeLog:
>
> * doc/install.texi: Document bootstrap-native.
> ---
>  config/bootstrap-native.mk | 1 +
>  gcc/doc/install.texi   | 7 +++
>  2 files changed, 8 insertions(+)
>  create mode 100644 config/bootstrap-native.mk
>
> diff --git a/config/bootstrap-native.mk b/config/bootstrap-native.mk
> new file mode 100644
> index 000..a4a3d859408
> --- /dev/null
> +++ b/config/bootstrap-native.mk
> @@ -0,0 +1 @@
> +BOOT_CFLAGS := -march=native -mtune=native $(BOOT_CFLAGS)

bootstrap-O3 uses

BOOT_CFLAGS := -O3 $(filter-out -O%, $(BOOT_CFLAGS))

so do you want to filer-out other -march/-mtune/-mcpu options?

Some targets know -mcpu= instead of -march=, did you check whether
any of those have =native?

> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 4973f195daf..04a2256b97a 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -3052,6 +3052,13 @@ Removes any @option{-O}-started option from 
> @code{BOOT_CFLAGS}, and adds
>  @itemx @samp{bootstrap-Og}
>  Analogous to @code{bootstrap-O1}.
>
> +@item @samp{bootstrap-native}
> +@itemx @samp{bootstrap-native}
> +Optimize the compiler code for the build host, if supported by the
> +architecture. Note this only affects the compiler, not the targeted
> +code. If you want the later, choose options suitable to the target you
> +are looking for. For example @samp{--with-cpu} would be a good starting 
> point.
> +
>  @item @samp{bootstrap-lto}
>  Enables Link-Time Optimization for host tools during bootstrapping.
>  @samp{BUILD_CONFIG=bootstrap-lto} is equivalent to adding
> --
> 2.47.1
>

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote:
> what about trunk then?  Right now, cobol still doesn't build there on
> Solaris/amd64 because 3 patches are missing:
> 
>   cobol: Don't require GLOB_BRACE etc. [PR119217]
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680675.html
> 
> Still unreviewed.
> 
>   cobol: Initialize regmatch_t portably [PR119217]
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680676.html
> 
> Unclear how exactly to handle this.
> 
>   cobol: Allow for undefined NAME_MAX [PR119217]
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680682.html
> 
> Should go for a variant simply replacing NAME_MAX by its Linux
>  value (255) until the whole struct cbl_function_t.name thing
> can be resolved.  Already tested on Linux/x86_64 and Solaris/amd64.
> 
> libgcobol does build on Solaris (at least on trunk) since
> 
> commit a619a128c992b2121a862b8470960ae751d25db6
> Author: Rainer Orth 
> Date:   Mon Apr 21 15:59:14 2025 +0200
> 
> libgcobol: Check for struct tm tm_zone

I think your patch should go to trunk for now as well and then like for 15.2
we can gradually extend or remove the whitelists as it is tested on more
hosts and targets and confirmed to work reasonably well.

Jakub

[PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

[Rainer Orth]

The Linux/sparc64 libstdc++ baselines haven't been updated for years.
This patch fixes that.

Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.

Ok for both?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2025-04-21  Rainer Orth  

libstdc++-v3:
* config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: Regenerate.
* config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: Likewise.

# HG changeset patch
# Parent  6e1c8d574bb5da758b42164fa71780ef10a9ec50
libstdc++: Update Linux/sparc64 baselines for GCC 15.1

diff --git a/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
@@ -199,6 +199,14 @@ FUNC:_ZNK11__gnu_debug16_Error_formatter
 FUNC:_ZNK11__gnu_debug16_Error_formatter8_M_errorEv@@GLIBCXX_3.4
 FUNC:_ZNK11__gnu_debug19_Safe_iterator_base11_M_singularEv@@GLIBCXX_3.4
 FUNC:_ZNK11__gnu_debug19_Safe_iterator_base14_M_can_compareERKS0_@@GLIBCXX_3.4
+FUNC:_ZNKRSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
 FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5
 FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@GLIBCXX_3.4
 FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofEPKwj@@GLIBCXX_3.4
@@ -467,6 +475,7 @@ FUNC:_ZNKSt10moneypunctIwLb1EE8groupingE
 FUNC:_ZNKSt10ostrstream5rdbufEv@@GLIBCXX_3.4
 FUNC:_ZNKSt10ostrstream6pcountEv@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPKc@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPPKc@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIcE15_M_date_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_time_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE19_M_days_abbreviatedEPPKc@@GLIBCXX_3.4
@@ -477,6 +486,7 @@ FUNC:_ZNKSt11__timepunctIcE7_M_daysEPPKc
 FUNC:_ZNKSt11__timepunctIcE8_M_am_pmEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE9_M_monthsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPKw@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPPKw@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIwE15_M_date_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_time_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE19_M_days_abbreviatedEPPKw@@GLIBCXX_3.4
@@ -487,7 +497,12 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
 FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
 FUNC:_ZNKSt12strstreambuf6pcountEv@@GLIBCXX_3.4
@@ -658,6 +673,13 @@ FUNC:_ZNKSt5ctypeIwE8do_widenEPKcS2_Pw@@
 FUNC:_ZNKSt5ctypeIwE8do_widenEc@@GLIBCXX_3.4
 FUNC:_ZNKSt5ctypeIwE9do_narrowEPKwS2_cPc@@GLIBCXX_3.4
 FUNC:_ZNKSt5ctypeIwE9do_narrowEwc@@GLIBCXX_3.4
+FUNC:_ZNKSt6chrono4tzdb11locate_zoneESt17basic_string_viewIcSt11char_traitsIcEE@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono4tzdb12current_zoneEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9time_zone15_M_get_sys_infoENS_10time_pointINS_3_V212system_clockENS_8durationIxSt5ratioILx1ELx1EE@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9time_zone17_M_get_local_infoENS_10time_pointINS_7local_tENS_8durationIxSt5ratioILx1ELx1EE@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9tzdb_list14const_iteratordeEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9tzdb_list5beginEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9tzdb_list5frontEv@@GLIBCXX_3.4.31
 FUNC:_ZNKSt6locale2id5_M_idEv@@GLIBCXX

[PATCH] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

[Tomasz Kamiński]

This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.

To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.

As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
 * _CharT is constrained __formatter::__char
 * basic_format_parse_context<_CharT> for parse argument
 * basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.

Furthermore the standard specifies these formatters as delegating to
formatter, charT>, which in turn
delegates to range_formatter. This patch avoids one lever of indirection,
and dependency of ranges::ref_view.  This is technically observable if
user specializes formatter> where PD is program defined
container, but I do not think this is the case worth extra indirection.

This patch also moves the formattable and it's dependencies to the formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator>, to struct with type nested typedef
that points to same type, that is forward declared.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in declaration
in bits/formatfwd.h.
* include/std/queue (formatter, 
_CharT>)
(formatter, _CharT>): Define.
* include/std/stack (formatter, 
_CharT>):
Define.
* testsuite/std/format/ranges/adaptors.cc: New test.
---
I plan to update feature test macro in separate commit, after confirming that
everything is implemented. OK for trunk?

I think we need `__format::__char` constrain for thread::id, as we also
use friend to provide private acess. I plan to create commit that will
do that, and also change include to formatfwd.h.

 libstdc++-v3/include/bits/formatfwd.h |  78 +
 libstdc++-v3/include/bits/stl_queue.h |  14 ++
 libstdc++-v3/include/bits/stl_stack.h |   9 +
 libstdc++-v3/include/std/format   |  76 +
 libstdc++-v3/include/std/queue|  74 +
 libstdc++-v3/include/std/stack|  42 +
 .../testsuite/std/format/ranges/adaptors.cc   | 156 ++
 7 files changed, 381 insertions(+), 68 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/adaptors.cc

diff --git a/libstdc++-v3/include/bits/formatfwd.h 
b/libstdc++-v3/include/bits/formatfwd.h
index a6b5ac8c8ce..9ba658b078a 100644
--- a/libstdc++-v3/include/bits/formatfwd.h
+++ b/libstdc++-v3/include/bits/formatfwd.h
@@ -37,6 +37,12 @@
 //  must have been included before this header:
 #ifdef __glibcxx_format // C++ >= 20 && HOSTED
 
+#include 
+#include 
+#if __glibcxx_format_ranges // C++ >= 23 && HOSTED
+#  include   // input_range, range_reference_t
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -50,6 +56,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // [format.formatter], formatter
   template struct formatter;
 
+/// @cond undocumented
 namespace __format
 {
 #ifdef _GLIBCXX_USE_WCHAR_T
@@ -60,9 +67,80 @@ namespace __format
 concept __char = same_as<_CharT, char>;
 #endif
 
+  template>,
+  typename _ParseContext
+= basic_format_parse_context>
+concept __parsable_with
+  = semiregular<_Formatter>
+ && requires (_Formatter __f, _ParseContext __pc)
+{
+  { __f.parse(__pc) } -> same_as;
+};
+
+  template>,
+  typename _ParseContex

Re: Improve vectorizer costs of min, max, abs, absu and const_expr on x86

[Richard Biener]

On Mon, 21 Apr 2025, Jan Hubicka wrote:

> Hi,
> this patch adds special cases for vectorizer costs in COND_EXPR, MIN_EXPR,
> MAX_EXPR, ABS_EXPR and ABSU_EXPR.   We previously costed ABS_EXPR and 
> ABSU_EXPR
> but it was only correct for FP variant (wehre it corresponds to andss clearing
> sign bit).  Integer abs/absu is open coded as conditinal move for SSE2 and
> SSE3 instroduced an instruction.
> 
> MIN_EXPR/MAX_EXPR compiles to minss/maxss for FP and accroding to Agner Fog
> tables they costs same as sse_op on all targets. Integer translated to single
> instruction since SSE3.
> 
> COND_EXPR translated to open-coded conditional move for SSE2, SSE4.1 
> simplified
> the sequence and AVX512 introduced masked registers.
> 
> The patch breaks gcc.target/i386/pr89618-2.c:
> 
> /* { dg-do compile } */
> /* { dg-options "-O3 -mavx2 -mno-avx512f -fdump-tree-vect-details" } */
> 
> void foo (int n, int *off, double *a)
> {
>   const int m = 32;
> 
>   for (int j = 0; j < n/m; ++j)
> {
>   int const start = j*m;
>   int const end = (j+1)*m;
> 
> #pragma GCC ivdep
>   for (int i = start; i < end; ++i)
>   {
> a[off[i]] = a[i] < 0 ? a[i] : 0;
>   }
> }
> }
> 
> /* Make sure the cost model selects SSE vectors rather than AVX to avoid
>too many scalar ops for the address computes in the loop.  */
> /* { dg-final { scan-tree-dump "loop vectorized using 16 byte vectors" "vect" 
> { target { ! ia32 } } } } */
> 
> here instead of SSSE
> 
> .L3:
>   vmovupd (%rcx), %xmm2
>   vmovupd 16(%rcx), %xmm1
>   addl$1, %esi
>   subq$-128, %rax
>   movslq  -124(%rax), %r9
>   movslq  -116(%rax), %rdi
>   addq$256, %rcx
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   movslq  -120(%rax), %r8
>   movslq  -128(%rax), %r10
>   vandpd  %xmm4, %xmm2, %xmm2
>   vandpd  %xmm3, %xmm1, %xmm1
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   movslq  -112(%rax), %r10
>   vmovhpd %xmm2, (%rdx,%r9,8)
>   movslq  -108(%rax), %r9
>   vmovlpd %xmm1, (%rdx,%r8,8)
>   movslq  -104(%rax), %r8
>   vmovhpd %xmm1, (%rdx,%rdi,8)
>   vmovupd -224(%rcx), %xmm2
>   movslq  -100(%rax), %rdi
>   vmovupd -208(%rcx), %xmm1
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vandpd  %xmm4, %xmm2, %xmm2
>   vandpd  %xmm3, %xmm1, %xmm1
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   movslq  -96(%rax), %r10
>   vmovhpd %xmm2, (%rdx,%r9,8)
>   movslq  -92(%rax), %r9
>   vmovlpd %xmm1, (%rdx,%r8,8)
>   movslq  -88(%rax), %r8
>   vmovhpd %xmm1, (%rdx,%rdi,8)
>   vmovupd -192(%rcx), %xmm2
>   movslq  -84(%rax), %rdi
>   vmovupd -176(%rcx), %xmm1
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vandpd  %xmm4, %xmm2, %xmm2
>   vandpd  %xmm3, %xmm1, %xmm1
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   vmovhpd %xmm2, (%rdx,%r9,8)
>   vmovlpd %xmm1, (%rdx,%r8,8)
>   vmovhpd %xmm1, (%rdx,%rdi,8)
>   vmovupd -160(%rcx), %xmm2
>   vmovupd -144(%rcx), %xmm1
>   movslq  -76(%rax), %r9
>   movslq  -68(%rax), %rdi
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   movslq  -72(%rax), %r8
>   movslq  -80(%rax), %r10
>   vandpd  %xmm4, %xmm2, %xmm2
>   vandpd  %xmm3, %xmm1, %xmm1
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   movslq  -64(%rax), %r10
>   vmovhpd %xmm2, (%rdx,%r9,8)
>   movslq  -60(%rax), %r9
>   vmovlpd %xmm1, (%rdx,%r8,8)
>   movslq  -56(%rax), %r8
>   vmovhpd %xmm1, (%rdx,%rdi,8)
>   vmovupd -128(%rcx), %xmm2
>   vmovupd -112(%rcx), %xmm1
>   movslq  -52(%rax), %rdi
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   vandpd  %xmm3, %xmm1, %xmm1
>   vandpd  %xmm4, %xmm2, %xmm2
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   movslq  -48(%rax), %r10
>   vmovhpd %xmm2, (%rdx,%r9,8)
>   movslq  -44(%rax), %r9
>   vmovlpd %xmm1, (%rdx,%r8,8)
>   movslq  -40(%rax), %r8
>   vmovhpd %xmm1, (%rdx,%rdi,8)
>   vmovupd -96(%rcx), %xmm2
>   vmovupd -80(%rcx), %xmm1
>   movslq  -36(%rax), %rdi
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   vandpd  %xmm3, %xmm1, %xmm1
>   vandpd  %xmm4, %xmm2, %xmm2
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   vmovhpd %xmm2, (%rdx,%r9,8)
>   movslq  -28(%rax), %r9
>   vmovlpd %xmm1, (%rdx,%r8,8)
>   vmovhpd %xmm1, (%rdx,%rdi,8)
>   vmovupd -64(%rcx), %xmm2
>   vmovupd -48(%rcx), %xmm1
>   movslq  -20(%rax), %rdi
>   movslq  -24(%rax), %r8
>   vcmpltpd%xmm0, %xmm1, %xmm3
>   vcmpltpd%xmm0, %xmm2, %xmm4
>   movslq  -32(%rax), %r10
>   vandpd  %xmm4, %xmm2, %xmm2
>   vandpd  %xmm3, %xmm1, %xmm1
>   vmovlpd %xmm2, (%rdx,%r10,8)
>   movslq  -16(%rax), %r10
>

Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 'targetm.arm_eabi_unwinder' [PR118794] (was: [Linaro-TCWG-CI] gcc-15-9463-gaa3e72f9430: 2 regressions on arm)

[Thomas Schwinge]

Hi!

On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression 
 wrote:
> Our automatic CI has detected problems related to your patch(es). Please find 
> some details below.
>
> In bootstrap_check master-arm-check_bootstrap, after:
>   | commit gcc-15-9463-gaa3e72f9430
>   | Author: Thomas Schwinge 
>   | Date:   Thu Mar 27 23:06:37 2025 +0100
>   | 
>   | Add test cases for exception handling constructs in dead code for 
> GCN, nvptx target and OpenMP 'target' offloading [PR118794]
>   | 
>   | PR target/118794
>   | gcc/testsuite/
>   | * g++.target/gcn/exceptions-pr118794-1.C: New.
>   | ... 7 lines of the commit log omitted.
>
> Produces 2 regressions:
>   | 
>   | regressions.sum:
>   | Running libgomp:libgomp.c++/c++.exp ...
>   | FAIL: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times 
> optimized "gimple_call <__builtin_eh_pointer, " 1
>   | FAIL: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times 
> optimized "gimple_call <__builtin_unwind_resume, " 1

Ah, sorry for that.  This is due to 'targetm.arm_eabi_unwinder', as per:

gcc/config/arm/arm.cc:#define TARGET_ARM_EABI_UNWINDER true
gcc/config/c6x/c6x.cc:#define TARGET_ARM_EABI_UNWINDER true

..., which for ARM is conditional to '#if ARM_UNWIND_INFO' (defined in
'gcc/config/arm/bpabi.h', used for various GCC configurations), and for
C6x unconditional.

This gets us:

--- target-exceptions-pr118794-1.C.269t.optimized
+++ target-exceptions-pr118794-1.C.270t.optimized
[...]
 __attribute__((omp declare target))
 void f ()
[...]
   gimple_call <__dt_comp , NULL, &c>
-  gimple_call <__builtin_eh_pointer, _7, 2>
-  gimple_call <__builtin_unwind_resume, NULL, _7>
+  gimple_call <__builtin_cxa_end_cleanup, NULL>
 
 }
[...]

There doesn't appear to be an effective-target keyword for
'targetm.arm_eabi_unwinder' specifically, do we need to add one?
Or, other test cases appear to use effective-target 'arm_eabi' to
disambiguate the two variants; is that the right thing to use here, too?
(..., plus 'tic6x-*-*' in this case?)  OK to push the attached
"Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 
'targetm.arm_eabi_unwinder' [PR118794]"?
(Could Arm/C6x maintainers please test this for me?)


Grüße
 Thomas


> Used configuration :
>  *CI config* tcwg_bootstrap_check master-arm-check_bootstrap
>  *configure and test flags:* none, autodetected on 
> armv8l-unknown-linux-gnueabihf
>
> We track this bug report under https://linaro.atlassian.net/browse/GNU-1562. 
> Please let us know if you have a fix.
>
> If you have any questions regarding this report, please ask on 
> linaro-toolch...@lists.linaro.org mailing list.
>
> -8<--8<--8<--
>
> The information below contains the details of the failures, and the ways to 
> reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
>  * 
> https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts/00-sumfiles/
> The full lists of regressions and improvements as well as configure and make 
> commands are in
>  * 
> https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts/notify/
> The list of [ignored] baseline and flaky failures are in
>  * 
> https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts/sumfiles/xfails.xfail
>
> Current build   : 
> https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts
> Reference build : 
> https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1235/artifact/artifacts
>
> Instruction to reproduce the build : 
> https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/aa3e72f943032e5f074b2bd2fd06d130dda8760b/tcwg_bootstrap_check/master-arm-check_bootstrap/reproduction_instructions.txt
>
> Full commit : 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=aa3e72f943032e5f074b2bd2fd06d130dda8760b


>From 423af3203bd9ebcf1f472f244c8e0d698163967f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 22 Apr 2025 13:41:22 +0200
Subject: [PATCH] Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for
 'targetm.arm_eabi_unwinder' [PR118794]

Fix-up for commit aa3e72f943032e5f074b2bd2fd06d130dda8760b
"Add test cases for exception handling constructs in dead code for GCN, nvptx target and OpenMP 'target' offloading [PR118794]":
we need to adjust for configurations with 'targetm.arm_eabi_unwinder', as per:

gcc/config/arm/arm.cc:#define TARGET_ARM_EABI_UNWINDER true
gcc/config/c6x/c6x.cc:#define TARGET_ARM_EABI_UNWINDER true

..., which for ARM is conditional to '#if ARM_UNWIND_INFO' (defined in
'gcc/config/arm/bpabi.h', used for various GCC configurations), and for
C6x unconditional.

This gets us:

Re: [PATCH v2] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 12:19, Tomasz Kamiński  wrote:
>
> This patch implements formatter specializations for standard container 
> adaptors
> (queue, priority_queue and stack) from P2286R8.
>
> To be able to access the protected `c` member, the adaptors befriend
> corresponding formatter specializations. Note that such specialization
> may be disable if the container is formattable, in such case
> specializations are unharmful.
>
> As in the case of previous commits, the signatures of the user-facing parse
> and format methods of the provided formatters deviate from the standard by
> constraining types of parameters:
>  * _CharT is constrained __formatter::__char
>  * basic_format_parse_context<_CharT> for parse argument
>  * basic_format_context<_Out, _CharT> for format second argument
> The standard specifies all above as unconstrained types. In particular
> _CharT constrain, allow us to befriend all allowed specializations.
>
> Furthermore the standard specifies these formatters as delegating to
> formatter, charT>, which in turn
> delegates to range_formatter. This patch avoids one level of indirection,
> and dependency of ranges::ref_view.  This is technically observable if
> user specializes formatter> where PD is program defined
> container, but I do not think this is the case worth extra indirection.
>
> This patch also moves the formattable and it's dependencies to the 
> formatfwd.h,
> so it can be used in adapters formatters, without including format header.
> The definition of _Iter_for is changed from alias to denoting
> back_insert_iterator>, to struct with type nested typedef
> that points to same type, that is forward declared.
>
> PR libstdc++/109162
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/formatfwd.h (__format::__parsable_with)
> (__format::__formattable_with, __format::__formattable_impl)
> (__format::__has_debug_format, __format::__const_formattable_range)
> (__format::__maybe_const_range, __format::__maybe_const)
> (std::formattable): Moved from std/format.
> (__format::Iter_for, std::range_formatter): Forward declare.
> * include/bits/stl_queue.h (std::formatter): Forward declare.
> (std::queue, std::priority_queue): Befriend formatter specializations.
> * include/bits/stl_stack.h (std::formatter): Forward declare.
> (std::stack): Befriend formatter specializations.
> * include/std/format (__format::_Iter_for): Define as struct with
> (__format::__parsable_with, __format::__formattable_with)
> (__format::__formattable_impl, __format::__has_debug_format)
> (_format::__const_formattable_range, __format::__maybe_const_range)
> (__format::__maybe_const, std::formattable): Moved to 
> bits/formatfwd.h.
> (std::range_formatter): Remove default argument specified in 
> declaration
> in bits/formatfwd.h.
> * include/std/queue: Include bits/version.h before bits/stl_queue.h.
> (formatter, _CharT>)
> (formatter, _CharT>): 
> Define.
> * include/std/stack: Include bits/version.h before bits/stl_stack.h
> (formatter, _CharT>): Define.
> * testsuite/std/format/ranges/adaptors.cc: New test.
>
> Reviewed-by: Jonathan Wakely 
> Signed-off-by: Tomasz Kamiński 
> ---
> Applied changes to feature test macros. Also in queue/stack files
> included bits/version.h before bits/stl_queue.h.
>
> OK for trunk?

Looks good, but as it moves things around between headers let's wait
until after 15.1 is released. That way the contents of
 won't diverge too much between trunk and gcc-15.

After 15.1 is released, this is OK for trunk and for gcc-15 (so that
15.2 will have full range formatting support).


>  libstdc++-v3/include/bits/formatfwd.h |  78 +
>  libstdc++-v3/include/bits/stl_queue.h |  14 ++
>  libstdc++-v3/include/bits/stl_stack.h |   9 +
>  libstdc++-v3/include/std/format   |  76 +
>  libstdc++-v3/include/std/queue|  80 -
>  libstdc++-v3/include/std/stack|  48 +-
>  .../testsuite/std/format/ranges/adaptors.cc   | 156 ++
>  7 files changed, 387 insertions(+), 74 deletions(-)
>  create mode 100644 libstdc++-v3/testsuite/std/format/ranges/adaptors.cc
>
> diff --git a/libstdc++-v3/include/bits/formatfwd.h 
> b/libstdc++-v3/include/bits/formatfwd.h
> index a6b5ac8c8ce..9ba658b078a 100644
> --- a/libstdc++-v3/include/bits/formatfwd.h
> +++ b/libstdc++-v3/include/bits/formatfwd.h
> @@ -37,6 +37,12 @@
>  //  must have been included before this header:
>  #ifdef __glibcxx_format // C++ >= 20 && HOSTED
>
> +#include 
> +#include 
> +#if __glibcxx_format_ranges // C++ >= 23 && HOSTED
> +#  include   // input_range, range_reference_t
> +#endif
> +
>  namespace std _GLIBCXX_VISIBILITY(default)
>  {
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
> @@ -50,6 +56,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>// [format.formatter]

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Sam James]

Jakub Jelinek  writes:

> On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
>> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek  wrote:
>> >
>> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> > > That's one option, but maybe it's better the other way round: instead of
>> > > excluding known-bad targets, restrict cobol to known-good ones
>> > > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
>> > >
>> > > I've been using the following for this (should be retested for safety).
>> >
>> > I admit I don't really know what works and what doesn't out of the box now,
>> > but your patch looks reasonable to me for 15 branch.
>> >
>> > Richard, Robert and/or James, do you agree?
>> 
>> I agree to restrict =all to enable cobol only for known-good platform 
>> triples.
>> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to allow
>
> But libgcobol configure.tgt does it only for the target case.
> Much more important right now is the host whitelist case.
> The code in the FE is still not sufficiently portable and so even
> i686-solaris -> x86_64-linux --enable-languages=all cross just won't build out
> of the box (and even if it would, it wouldn't work properly).
> Or x86_64-freebsd -> x86_64-linux might not either.
>
> So, I think we want Rainer's patch here.
>

I thought about it further after discussion on IRC and I agree. Rainer's
looks good.

>> a cobol build with explicit 'cobol' included even when configure.tgt claims
>> unsupported?  So why's *-*solaris now included in =all?
>> 
>> I'm a bit confused, I thought we had =all restricted already.
>
>> > > 2025-03-17  Rainer Orth  
>> > >
>> > >   PR cobol/119217
>> > >   * configure.ac: Restrict cobol to aarch64-*-linux*,
>> > >   x86_64-*-linux*.
>> > >   * configure: Regenerate.
>
>   Jakub

[PATCH] libstdc++: Update baseline_symbols.txt for {x86_64,i486,powerpc64le,s390x,aarch64}-linux

[Jakub Jelinek]

Hi!

We forgot to update these timely, sorry for that, the following patch
updates them from the 15.1-rc1 builds in Fedora.

Ok for trunk and 15?

2025-04-22  Jakub Jelinek  

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.

--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
2024-04-11 16:37:22.625001351 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
2025-04-22 09:52:38.360802666 +0200
@@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
@@ -3221,6 +3225,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcm@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcm@@GLIBCXX_3.4.34
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3374,6 +3380,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEmw@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwm@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwm@@GLIBCXX_3.4.34
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3941,6 +3949,8 @@ FUNC:_ZNSt8__detail15_List_node_base11_M
 FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
+FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
+FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
 FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
@@ -4617,6 +4627,7 @@ OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
 OBJECT:0:GLIBCXX_3.4.33
+OBJECT:0:GLIBCXX_3.4.34
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj
2024-04-11 16:37:22.627001324 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt   
2025-04-22 09:52:51.946619578 +0200
@@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3

Re: [PHASE1 PATCH] Use optimize free lists for alloc_pages

[Richard Biener]

On Fri, Apr 11, 2025 at 6:10 PM Andi Kleen  wrote:
>
> Right now ggc has a single free list for multiple sizes. In some cases
> the list can get mixed by orders and then the allocator may spend a lot
> of time walking the free list to find the right sizes.
>
> This patch splits the free list into multiple free lists by order
> which allows O(1) access in most cases.
>
> It also has a fallback list for sizes not in the free lists
> (that seems to be needed for now)
>
> For the PR119387 test case it gives a significant speedup,
> both with and without debug information.
>
> Potential drawback might be some more fragmentation in the memory
> map, so there is a risk that very large compilations may run into
> the vma limit on Linux, or have slightly less coverage with
> large pages.
>
> For the PR119387 test case which have extra memory overhead with -ggdb:
>
>   ../obj-fast/gcc/cc1plus-allocpage -std=gnu++20 -O2 pr119387.cc -quiet
> ran 1.04 ± 0.01 times faster than ../obj-fast/gcc/cc1plus -std=gnu++20 
> -O2 pr119387.cc  -quiet
> 2.63 ± 0.01 times faster than ../obj-fast/gcc/cc1plus-allocpage 
> -std=gnu++20 -O2 pr119387.cc  -quiet -ggdb
> 2.78 ± 0.01 times faster than ../obj-fast/gcc/cc1plus -std=gnu++20 
> -O2 pr119387.cc  -quiet -ggdb
>
> It might also help for other test cases creating a lot of garbage.

I assume this passed bootstrap & regtest?

This is OK for trunk after we've released GCC 15.1.

Thanks,
Richard.

> gcc/ChangeLog:
>
> PR middle-end/114563
> PR c++/119387
> * ggc-page.cc (struct free_list): New structure.
> (struct page_entry): Point to free_list.
> (find_free_list): New function.
> (find_free_list_order): Dito.
> (alloc_page): Use specific free_list.
> (release_pages): Dito.
> (do_release_pages): Dito.
> (init_ggc): Dito.
> (ggc_print_statistics): Print overflow stat.
> (ggc_pch_read): Use specific free list.
> ---
>  gcc/ggc-page.cc | 110 
>  1 file changed, 92 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/ggc-page.cc b/gcc/ggc-page.cc
> index 971b4334b7c2..0f674c0d6d7c 100644
> --- a/gcc/ggc-page.cc
> +++ b/gcc/ggc-page.cc
> @@ -234,6 +234,8 @@ static struct
>  }
>  inverse_table[NUM_ORDERS];
>
> +struct free_list;
> +
>  /* A page_entry records the status of an allocation page.  This
> structure is dynamically sized to fit the bitmap in_use_p.  */
>  struct page_entry
> @@ -251,6 +253,9 @@ struct page_entry
>   of the host system page size.)  */
>size_t bytes;
>
> +  /* Free list of this page size.  */
> +  struct free_list *free_list;
> +
>/* The address at which the memory is allocated.  */
>char *page;
>
> @@ -368,6 +373,15 @@ struct free_object
>  };
>  #endif
>
> +constexpr int num_free_list = 8;
> +
> +/* A free_list for pages with BYTES size.  */
> +struct free_list
> +{
> +  size_t bytes;
> +  page_entry *free_pages;
> +};
> +
>  /* The rest of the global variables.  */
>  static struct ggc_globals
>  {
> @@ -412,8 +426,8 @@ static struct ggc_globals
>int dev_zero_fd;
>  #endif
>
> -  /* A cache of free system pages.  */
> -  page_entry *free_pages;
> +  /* A cache of free system pages. Entry 0 is fallback.  */
> +  struct free_list free_lists[num_free_list];
>
>  #ifdef USING_MALLOC_PAGE_GROUPS
>page_group *page_groups;
> @@ -488,6 +502,9 @@ static struct ggc_globals
>
>  /* The overhead for each of the allocation orders.  */
>  unsigned long long total_overhead_per_order[NUM_ORDERS];
> +
> +/* Number of fallbacks.  */
> +unsigned long long fallback;
>} stats;
>  } G;
>
> @@ -754,6 +771,42 @@ clear_page_group_in_use (page_group *group, char *page)
>  }
>  #endif
>
> +/* Find a free list for ENTRY_SIZE.  */
> +
> +static inline struct free_list *
> +find_free_list (size_t entry_size)
> +{
> +  int i;
> +  for (i = 1; i < num_free_list; i++)
> +{
> +  if (G.free_lists[i].bytes == entry_size)
> +   return &G.free_lists[i];
> +  if (G.free_lists[i].bytes == 0)
> +   {
> + G.free_lists[i].bytes = entry_size;
> + return &G.free_lists[i];
> +   }
> +}
> +  /* Fallback. Does this happen?  */
> +  if (GATHER_STATISTICS)
> +G.stats.fallback++;
> +  return &G.free_lists[0];
> +}
> +
> +/* Fast lookup of free_list by order.  */
> +
> +static struct free_list *cache_free_list[NUM_ORDERS];
> +
> +/* Faster way to find a free list by ORDER for BYTES.  */
> +
> +static inline struct free_list *
> +find_free_list_order (unsigned order, size_t bytes)
> +{
> +  if (cache_free_list[order] == NULL)
> +cache_free_list[order] = find_free_list (bytes);
> +  return cache_free_list[order];
> +}
> +
>  /* Allocate a new page for allocating objects of size 2^ORDER,
> and return an entry for it.  The entry is not added to the
> appropriate page_table list.  */
> @@ -770,6 +823,7 @@ alloc_page (unsigned order)
>  #ifdef USING_

Re: [PATCH stage1 0/6] Correct outgoing integer argument promotion

[Richard Biener]

On Fri, Mar 14, 2025 at 11:51 PM H.J. Lu  wrote:
>
> 1. Honor TARGET_PROMOTE_PROTOTYPES during RTL expand.
> 2. Drop targetm.promote_prototypes from C, C++ and Ada frontends.
> 3. Adjust tests for the C frontend promotion removal.
> 4. gcc.dg/tree-ssa/pr108357.c fails with the C frontend promotion removal.
> This is a known issue:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357

This series is OK for trunk after 15.1 is released.  Thanks a lot for
tackling this.

Richard.

> H.J. Lu (6):
>   Honor TARGET_PROMOTE_PROTOTYPES during RTL expand
>   Drop targetm.promote_prototypes from C, C++ and Ada frontends
>   i386: Adjust apx-ndd.c for frontend promotion removal
>   vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86
>   scev-cast.c: Enable for all targets and adjust scan matches
>   ssa-fre-4.c: Enable for all targets and adjust scan match
>
>  gcc/ada/gcc-interface/utils.cc| 24 ---
>  gcc/c/c-decl.cc   | 40 ---
>  gcc/c/c-typeck.cc | 19 ++---
>  gcc/calls.cc  |  9 +
>  gcc/cp/call.cc| 10 -
>  gcc/cp/typeck.cc  | 13 ++
>  gcc/gimple.cc | 10 +
>  gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c |  5 +--
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-4.c |  6 +--
>  .../gcc.dg/vect/vect-simd-clone-16c.c |  5 +--
>  .../gcc.dg/vect/vect-simd-clone-16d.c |  4 +-
>  .../gcc.dg/vect/vect-simd-clone-17c.c |  5 +--
>  .../gcc.dg/vect/vect-simd-clone-17d.c |  5 +--
>  .../gcc.dg/vect/vect-simd-clone-18c.c |  5 +--
>  .../gcc.dg/vect/vect-simd-clone-18d.c |  5 +--
>  gcc/testsuite/gcc.target/i386/apx-ndd.c   |  9 ++---
>  gcc/testsuite/gfortran.dg/pr112877-1.f90  | 17 
>  gcc/tree.cc   | 14 ---
>  18 files changed, 48 insertions(+), 157 deletions(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/pr112877-1.f90
>
> --
> 2.48.1
>

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Rainer Orth]

Hi Jakub,

> On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote:
>> what about trunk then?  Right now, cobol still doesn't build there on
>> Solaris/amd64 because 3 patches are missing:
>> 
>>  cobol: Don't require GLOB_BRACE etc. [PR119217]
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680675.html
>> 
>> Still unreviewed.
>> 
>>  cobol: Initialize regmatch_t portably [PR119217]
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680676.html
>> 
>> Unclear how exactly to handle this.
>> 
>>  cobol: Allow for undefined NAME_MAX [PR119217]
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680682.html
>> 
>> Should go for a variant simply replacing NAME_MAX by its Linux
>>  value (255) until the whole struct cbl_function_t.name thing
>> can be resolved.  Already tested on Linux/x86_64 and Solaris/amd64.
>> 
>> libgcobol does build on Solaris (at least on trunk) since
>> 
>> commit a619a128c992b2121a862b8470960ae751d25db6
>> Author: Rainer Orth 
>> Date:   Mon Apr 21 15:59:14 2025 +0200
>> 
>> libgcobol: Check for struct tm tm_zone
>
> I think your patch should go to trunk for now as well and then like for 15.2
> we can gradually extend or remove the whitelists as it is tested on more
> hosts and targets and confirmed to work reasonably well.

fine with me.  This way there's no hurry with the other patches for fear
of either breaking the build on non-Linux platforms or impacting COBOL
on Linux.

I'll go ahead with trunk and gcc-15 branch then.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Rainer Orth]

Jakub Jelinek  writes:

> On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote:
>> fine with me.  This way there's no hurry with the other patches for fear
>> of either breaking the build on non-Linux platforms or impacting COBOL
>> on Linux.
>
> No rush, sure, on the other side, better resolve all those in stage1...

Exactly, and then when we get closer to the GCC 15.2 release we can
check how well COBOL does on trunk on various platforms and consider
backporting the necessary patches to the gcc-15 branch.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote:
> fine with me.  This way there's no hurry with the other patches for fear
> of either breaking the build on non-Linux platforms or impacting COBOL
> on Linux.

No rush, sure, on the other side, better resolve all those in stage1...

Jakub

Re: [PATCH] testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

[Jørgen Kvalsvik]

Hi,

Thanks for fixing this. I just checked glibc, which implements 
__sigsetjmp as:


# define sigsetjmp(env, savemask) __sigsetjmp (env, savemask)

So I would think this is fine. I leave the ack to the Jakub, Richard et 
al, of course.


Thanks,
Jørgen

On 2025-04-22 10:33, Rainer Orth wrote:

The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:

FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5: 
error: implicit declaration of function '__sigsetjmp'; did you mean 
'sigsetjmp'? [-Wimplicit-function-declaration]


__sigsetjmp is a Linux/glibc implementation detail.  Other tests just
use sigsetjmp directly, so this patch follows suit.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, and x86_64-apple-darwin24.4.0.

Ok for trunk and the gcc-15 branch?

Rainer

[PATCH] s390: Allow 5+ argument tail-calls in some special cases [PR119873]

[Jakub Jelinek]

Hi!

protobuf (and therefore firefox too) currently doesn't build on s390*-linux.
The problem is that it uses [[clang::musttail]] attribute heavily, and in
llvm (IMHO llvm bug) [[clang::musttail]] calls with 5+ arguments on
s390*-linux are silently accepted and result in a normal non-tail call.
In GCC we just reject those because the target hook refuses to tail call it
(IMHO the right behavior).
Now, the reason why that happens is as s390_function_ok_for_sibcall attempts
to explain, the 5th argument (assuming normal <= wordsize integer or pointer
arguments, nothing that needs 2+ registers) is passed in %r6 which is not
call clobbered, so we can't do tail call when we'd have to change content
of that register and then caller would assume %r6 content didn't change and
use it again.
In the protobuf case though, the 5th argument is always passed through
from the caller to the musttail callee unmodified, so one can actually
emit just jg tail_called_function or perhaps tweak some registers but
keep %r6 untouched, and in that case I think it is just fine to tail call
it (at least unless the stack slots used for 6+ argument can't be modified
by the callee in the ABI and nothing checks for that).

So, the following patch checks for this special case, where the argument
which uses %r6 is passed in a single register and it is passed default
definition of SSA_NAME of a PARM_DECL with the same DECL_INCOMING_RTL.

It won't really work at -O0 but should work for -O1 and above, at least when
one doesn't really try to modify the parameter conditionally and hope it will
be optimized away in the end.

Bootstrapped/regtested on s390x-linux, ok for trunk?

I wonder if we shouldn't do this for 15.1 as well with additional
&& CALL_EXPR_MUST_TAIL_CALL (call_expr) check ideally after nregs == 1
so that we only do that for the musttail cases where we'd otherwise
error and not for anything else, to fix up protobuf/firefox out of the box.

2025-04-21  Jakub Jelinek  

PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same register
is passed in call saved register.
(s390_function_ok_for_sibcall): Adjust comment.

* gcc.target/s390/pr119873-1.c: New test.
* gcc.target/s390/pr119873-2.c: New test.

--- gcc/config/s390/s390.cc.jj  2025-04-14 07:26:46.441883927 +0200
+++ gcc/config/s390/s390.cc 2025-04-21 21:57:37.457535989 +0200
@@ -14496,7 +14496,21 @@ s390_call_saved_register_used (tree call
 
  for (reg = 0; reg < nregs; reg++)
if (!call_used_or_fixed_reg_p (reg + REGNO (parm_rtx)))
- return true;
+ {
+   rtx parm;
+   /* Allow passing through unmodified value from caller,
+  see PR119873.  */
+   if (nregs == 1
+   && TREE_CODE (parameter) == SSA_NAME
+   && SSA_NAME_IS_DEFAULT_DEF (parameter)
+   && SSA_NAME_VAR (parameter)
+   && TREE_CODE (SSA_NAME_VAR (parameter)) == PARM_DECL
+   && (parm = DECL_INCOMING_RTL (SSA_NAME_VAR (parameter)))
+   && REG_P (parm)
+   && rtx_equal_p (parm, parm_rtx))
+ break;
+   return true;
+ }
}
   else if (GET_CODE (parm_rtx) == PARALLEL)
{
@@ -14543,8 +14557,9 @@ s390_function_ok_for_sibcall (tree decl,
 return false;
 
   /* Register 6 on s390 is available as an argument register but unfortunately
- "caller saved". This makes functions needing this register for arguments
- not suitable for sibcalls.  */
+ "caller saved".  This makes functions needing this register for arguments
+ not suitable for sibcalls, unless the same value is passed from the
+ caller.  */
   return !s390_call_saved_register_used (exp);
 }
 
--- gcc/testsuite/gcc.target/s390/pr119873-1.c.jj   2025-04-21 
22:03:59.341568852 +0200
+++ gcc/testsuite/gcc.target/s390/pr119873-1.c  2025-04-21 22:03:54.277634719 
+0200
@@ -0,0 +1,11 @@
+/* PR target/119873 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+const char *foo (void *, void *, void *, void *, unsigned long, unsigned long);
+
+const char *
+bar (void *a, void *b, void *c, void *d, unsigned long e, unsigned long f)
+{
+  [[gnu::musttail]] return foo (a, b, c, d, e, f);
+}
--- gcc/testsuite/gcc.target/s390/pr119873-2.c.jj   2025-04-21 
22:04:06.150480291 +0200
+++ gcc/testsuite/gcc.target/s390/pr119873-2.c  2025-04-21 22:05:36.014311435 
+0200
@@ -0,0 +1,17 @@
+/* PR target/119873 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+const char *foo (void *, void *, void *, void *, unsigned long, unsigned long);
+
+const char *
+bar (void *a, void *b, void *c, void *d, unsigned long e, unsigned long f)
+{
+  [[gnu::musttail]] return foo (a, b, c, d, e + 1, f); /* { dg-error "cannot 
tail-call: target is not able to optim

[PATCH] testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

[Rainer Orth]

The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:

FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5: 
error: implicit declaration of function '__sigsetjmp'; did you mean 
'sigsetjmp'? [-Wimplicit-function-declaration]

__sigsetjmp is a Linux/glibc implementation detail.  Other tests just
use sigsetjmp directly, so this patch follows suit.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, and x86_64-apple-darwin24.4.0.

Ok for trunk and the gcc-15 branch?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2025-04-22  Rainer Orth  

testsuite:
* gcc.misc-tests/gcov-31.c (run_pending_traps): Use sigsetjmp
instead of __sigsetjmp.

# HG changeset patch
# Parent  b01221cbb2cd8adef7b141a88e91c7eb4db34aa1
testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

diff --git a/gcc/testsuite/gcc.misc-tests/gcov-31.c b/gcc/testsuite/gcc.misc-tests/gcov-31.c
--- a/gcc/testsuite/gcc.misc-tests/gcov-31.c
+++ b/gcc/testsuite/gcc.misc-tests/gcov-31.c
@@ -20,7 +20,7 @@ run_pending_traps ()
 jump_to_top_level (2);
 
   for (sig = 1; sig < (64 + 1) ; sig++)
-__sigsetjmp ((return_catch), 0);
+sigsetjmp ((return_catch), 0);
 }
 
 /* Distilled from alsalib-1.2.11 pcm/pcm_route.c.  */

Re: [PATCH] libstdc++: Finalize GCC 15 ABI

[Jonathan Wakely]

On Sat, 19 Apr 2025 at 13:12, Andreas Schwab  wrote:
>
> Disallow adding new symbols to GLIBCXX_3.4.34 and CXXABI_1.3.16 versions.
>
> * testsuite/util/testsuite_abi.cc (check_version): Update latestp
> to use GLIBCXX_3.4.35 and CXXABI_1.3.17.

OK for trunk, thanks.


> ---
>  libstdc++-v3/testsuite/util/testsuite_abi.cc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc 
> b/libstdc++-v3/testsuite/util/testsuite_abi.cc
> index 1b4044c9518..90cda2fbca8 100644
> --- a/libstdc++-v3/testsuite/util/testsuite_abi.cc
> +++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc
> @@ -258,8 +258,8 @@ check_version(symbol& test, bool added)
> test.version_status = symbol::incompatible;
>
>// Check that added symbols are added in the latest pre-release 
> version.
> -  bool latestp = (test.version_name == "GLIBCXX_3.4.34"
> -|| test.version_name == "CXXABI_1.3.16"
> +  bool latestp = (test.version_name == "GLIBCXX_3.4.35"
> +|| test.version_name == "CXXABI_1.3.17"
>  || test.version_name == "CXXABI_FLOAT128"
>  || test.version_name == "CXXABI_TM_1");
>if (added && !latestp)
> --
> 2.49.0
>
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

[Rainer Orth]

Hi Jonathan,

> On Tue, 22 Apr 2025 at 08:28, Rainer Orth  
> wrote:
>>
>> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
>> This patch fixes that.
>>
>> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>>
>> Ok for both?
>
> This adds:
>
> +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
>
> For the other linux targets we don't include those in the baselines.

ah, I missed that.  Patch adjusted accordingly and retested.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


# HG changeset patch
# Parent  74b0c7275786673565a7a1f3d30e96e324cc8708
libstdc++: Update Linux/sparc64 baselines for GCC 15.1

diff --git a/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
@@ -199,6 +199,14 @@ FUNC:_ZNK11__gnu_debug16_Error_formatter
 FUNC:_ZNK11__gnu_debug16_Error_formatter8_M_errorEv@@GLIBCXX_3.4
 FUNC:_ZNK11__gnu_debug19_Safe_iterator_base11_M_singularEv@@GLIBCXX_3.4
 FUNC:_ZNK11__gnu_debug19_Safe_iterator_base14_M_can_compareERKS0_@@GLIBCXX_3.4
+FUNC:_ZNKRSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
 FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5
 FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@GLIBCXX_3.4
 FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofEPKwj@@GLIBCXX_3.4
@@ -467,6 +475,7 @@ FUNC:_ZNKSt10moneypunctIwLb1EE8groupingE
 FUNC:_ZNKSt10ostrstream5rdbufEv@@GLIBCXX_3.4
 FUNC:_ZNKSt10ostrstream6pcountEv@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPKc@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPPKc@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIcE15_M_date_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_time_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE19_M_days_abbreviatedEPPKc@@GLIBCXX_3.4
@@ -477,6 +486,7 @@ FUNC:_ZNKSt11__timepunctIcE7_M_daysEPPKc
 FUNC:_ZNKSt11__timepunctIcE8_M_am_pmEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE9_M_monthsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPKw@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPPKw@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIwE15_M_date_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_time_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE19_M_days_abbreviatedEPPKw@@GLIBCXX_3.4
@@ -487,7 +497,12 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
 FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
 FUNC:_ZNKSt12strstreambuf6pcountEv@@GLIBCXX_3.4
@@ -658,6 +673,13 @@ FUNC:_ZNKSt5ctypeIwE8do_widenEPKcS2_Pw@@
 FUNC:_ZNKSt5ctypeIwE8do_widenEc@@GLIBCXX_3.4
 FUNC:_ZNKSt5ctypeIwE9do_narrowEPKwS2_cPc@@GLIBCXX_3.4
 FUNC:_ZNKSt5ctypeIwE9do_narrowEwc@@GLIBCXX_3.4
+FUNC:_ZNKSt6chrono4tzdb11locate_zoneESt17basic_string_viewIcSt11char_traitsIcEE@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono4tzdb12current_zoneEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9time_zone15_M_get_sys_infoENS_10time_pointINS_3_V212system_clockENS_8durationIxSt5ratioILx1ELx1EE@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9time_zone17_M_get_local_infoENS_10time_pointINS_7local_tENS_8durationIxSt5ratioILx1ELx1EE@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9tzdb_list14const_iteratordeEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt6chrono9tzdb

Re: [PATCH] testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

[Richard Biener]

On Tue, 22 Apr 2025, Rainer Orth wrote:

> The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:
> 
> FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)
> 
> Excess errors:
> /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5: 
> error: implicit declaration of function '__sigsetjmp'; did you mean 
> 'sigsetjmp'? [-Wimplicit-function-declaration]
> 
> __sigsetjmp is a Linux/glibc implementation detail.  Other tests just
> use sigsetjmp directly, so this patch follows suit.
> 
> Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
> x86_64-pc-linux-gnu, and x86_64-apple-darwin24.4.0.
> 
> Ok for trunk and the gcc-15 branch?

OK.

>   Rainer
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

[committed (Apr 17 to GCC 15 mainline)] libgomp.texi: For HIP interop, mention cpp defines to set

[Tobias Burnus]

I just saw that I seemingly have missed to send this patch also to the mailing 
list :-(

It was committed to what was back then still mainline GCC 15:r15-9545-g4bff3f0b89af9a Result after the patch: 
https://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-AMD-GPUs.html 
and 
https://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-Nvidia-GPUs.html 
Tobias
commit 4bff3f0b89af9a9aad69b8f85859c0a3667533ae
Author: Tobias Burnus 
Date:   Thu Apr 17 10:21:05 2025 +0200

libgomp.texi: For HIP interop, mention cpp defines to set

The HIP header files recognize the used compiler, defaulting to either AMD
or Nvidia/CUDA; thus, the alternative way of explicitly defining a macro is
less prominently documented. With GCC, the user has to define the
preprocessor macro manually. Hence, as a service to the user, mention
__HIP_PLATFORM_AMD__ and __HIP_PLATFORM_NVIDIA__ in the interop documentation,
even though it has only indirectly to do with GCC and its interop support.

Note to commit-log readers, only: For Fortran, the hipfort modules can be
used; when compiling the hipfort package (defaults to use gfortran), it
generates the module (*.mod) files in include/hipfort/{amdgcn,nvidia}/ such
that the choice is made by setting the respective include path.

libgomp/ChangeLog:

* libgomp.texi (gcn interop, nvptx interop): For HIP with C/C++, add
a note about setting a preprocessor define.
---
 libgomp/libgomp.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index dfd189b646e..6909c2b16f8 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -6945,6 +6945,9 @@ or string (str) data type, call @code{omp_get_interop_int},
 Note that @code{device_num} is the OpenMP device number
 while @code{device} is the HIP device number or HSA device handle.
 
+When using HIP with C and C++, the @code{__HIP_PLATFORM_AMD__} preprocessor
+macro must be defined before including the HIP header files.
+
 For the API routine call, add the prefix @code{omp_ipr_} to the property name;
 for instance:
 @smallexample
@@ -7107,6 +7110,9 @@ or string (str) data type, call @code{omp_get_interop_int},
 Note that @code{device_num} is the OpenMP device number while @code{device}
 is the CUDA, CUDA Driver, or HIP device number.
 
+When using HIP with C and C++, the @code{__HIP_PLATFORM_NVIDIA__} preprocessor
+macro must be defined before including the HIP header files.
+
 For the API routine call, add the prefix @code{omp_ipr_} to the property name;
 for instance:
 @smallexample

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64, i486, powerpc64le, s390x, aarch64}-linux

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 09:29, Jonathan Wakely  wrote:
>
> On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek  wrote:
> >
> > Hi!
> >
> > We forgot to update these timely, sorry for that, the following patch
> > updates them from the 15.1-rc1 builds in Fedora.
> >
> > Ok for trunk and 15?
> >
> > 2025-04-22  Jakub Jelinek  
> >
> > * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
> > * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: 
> > Update.
> >
> > --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
> > 2024-04-11 16:37:22.625001351 +0200
> > +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> > 2025-04-22 09:52:38.360802666 +0200
> > @@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
> >  
> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
> >  
> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
> >  
> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
> > +FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
>
> I'm curious where these come from, and why they are present now but
> weren't needed before.

Ah it's the changes for  formatting that also added these:

+FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
+FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34

So OK for trunk and gcc-15.


>
> >  FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
> >  FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
> >  FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
> > @@ -3221,6 +3225,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
> > +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcm@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcm@@GLIBCXX_3.4.34
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> > @@ -3374,6 +3380,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEmw@@GLIBCXX_3.4.21
> > +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwm@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwm@@GLIBCXX_3.4.34
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> > @@ -3941,6 +3949,8 @@ FUNC:_ZNSt8__detail15_List_node_base11_M
> >  FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
> >  FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
> >  FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
> > +FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
> >  FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
> >  FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
> >  FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
> > @@ -4617,6 +4627,7 @@ OBJECT:0:GLIBCXX_

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 15.1

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 09:04, Jakub Jelinek  wrote:
>
> On Tue, Apr 22, 2025 at 09:18:14AM +0200, Rainer Orth wrote:
> > This patch updates the Solaris libstdc++ baselines for GCC 15.1.
> >
> > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
> > gcc-15 branch and trunk.
> >
> > Ok for both?
> >
> >   Rainer
> >
> > --
> > -
> > Rainer Orth, Center for Biotechnology, Bielefeld University
> >
> >
> > 2025-02-11  Rainer Orth  
> >
> >   libstdc++-v3:
> >   * config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
> >   * config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
> >   Likewise.
> >   * config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
> >   * config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
> >   Likewise.
>
> This matches the changes I've posted for linux targets; if
> Jonathan approves this, it is ok for 15 branch too.

Yes OK for trunk and gcc-15, thanks.

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64,i486,powerpc64le,s390x,aarch64}-linux

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 09:29:16AM +0100, Jonathan Wakely wrote:
> On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek  wrote:
> > We forgot to update these timely, sorry for that, the following patch
> > updates them from the 15.1-rc1 builds in Fedora.
> >
> > Ok for trunk and 15?
> >
> > 2025-04-22  Jakub Jelinek  
> >
> > * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
> > * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: 
> > Update.
> >
> > --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
> > 2024-04-11 16:37:22.625001351 +0200
> > +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> > 2025-04-22 09:52:38.360802666 +0200
> > @@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
> >  
> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
> >  
> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
> >  
> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
> > +FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
> > +FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
> 
> I'm curious where these come from, and why they are present now but
> weren't needed before.

Are you going to investigate or should I?
Note, Rainer has it in his patches as well.

Jakub

RE: [PATCH] Add COBOL information to gcc.gnu.org index.html

[Gerald Pfeifer]

On Thu, 17 Apr 2025, Robert Dubner wrote:
> In the absence of commentary, I have pushed those documentation changes.

This is fine. You can also copy me on wwwdocs changes, though that's 
certainly not required (and I do have filters to focus on these on 
gcc-patches).

Gerald

[PATCH] Document locality partitioning params in invoke.texi

[Kyrylo Tkachov]

Hi all,

Filip Kastl pointed out that contrib/check-params-in-docs.py complains
about params not documented in invoke.texi, so this patch adds the short
explanation from params.opt for these to the invoke.texi section.
Thanks for the reminder.

Ok for trunk and GCC 15 branch?
Kyrill

Signed-off-by: Kyrylo Tkachov 

* invoke.texi (lto-partition-locality-frequency-cutoff,
lto-partition-locality-size-cutoff, lto-max-locality-partition):
Document.



0001-Document-locality-partitioning-params-in-invoke.texi.patch
Description: 0001-Document-locality-partitioning-params-in-invoke.texi.patch

Re: [PATCH] x86: Properly find the maximum stack slot alignment

[Uros Bizjak]

On Sun, Apr 20, 2025 at 11:26 PM H.J. Lu  wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers.  We first find all registers defined by stack or frame
> registers.  Then check memory accesses by such registers, including
> stack and frame registers.
>
> gcc/
>
> PR target/109780
> PR target/109093
> * config/i386/i386.cc (stack_access_data): New.
> (ix86_update_stack_alignment): Likewise.
> (ix86_find_all_reg_use_1): Likewise.
> (ix86_find_all_reg_use): Likewise.
> (ix86_find_max_used_stack_alignment): Also check memory accesses
> from registers defined by stack or frame registers.
>
> gcc/testsuite/
>
> PR target/109780
> PR target/109093
> * g++.target/i386/pr109780-1.C: New test.
> * gcc.target/i386/pr109093-1.c: Likewise.
> * gcc.target/i386/pr109780-1.c: Likewise.
> * gcc.target/i386/pr109780-2.c: Likewise.
> * gcc.target/i386/pr109780-3.c: Likewise.
>
> Signed-off-by: H.J. Lu 
> ---
>  gcc/config/i386/i386.cc| 174 ++---
>  gcc/testsuite/g++.target/i386/pr109780-1.C |  72 +
>  gcc/testsuite/gcc.target/i386/pr109093-1.c |  33 
>  gcc/testsuite/gcc.target/i386/pr109780-1.c |  14 ++
>  gcc/testsuite/gcc.target/i386/pr109780-2.c |  21 +++
>  gcc/testsuite/gcc.target/i386/pr109780-3.c |  46 ++
>  6 files changed, 339 insertions(+), 21 deletions(-)
>  create mode 100644 gcc/testsuite/g++.target/i386/pr109780-1.C
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr109093-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr109780-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr109780-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr109780-3.c
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 28603c2943e..9e4e76857e6 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -8473,6 +8473,103 @@ output_probe_stack_range (rtx reg, rtx end)
>return "";
>  }
>
> +/* Data passed to ix86_update_stack_alignment.  */
> +struct stack_access_data
> +{
> +  /* The stack access register.  */
> +  const_rtx reg;
> +  /* Pointer to stack alignment.  */
> +  unsigned int *stack_alignment;
> +};
> +
> +/* Update the maximum stack slot alignment from memory alignment in
> +   PAT.  */
> +
> +static void
> +ix86_update_stack_alignment (rtx, const_rtx pat, void *data)
> +{
> +  /* This insn may reference stack slot.  Update the maximum stack slot
> + alignment if the memory is referenced by the stack access register.
> +   */
> +  stack_access_data *p = (stack_access_data *) data;
> +  subrtx_iterator::array_type array;
> +  FOR_EACH_SUBRTX (iter, array, pat, ALL)
> +{
> +  auto op = *iter;
> +  if (GET_CODE (op) == ZERO_EXTEND)
> +   op = XEXP (op, 0);

No need for the above, FOR_EACH_SUBRTX will iterate over ZERO_EXTEND.

> +  if (MEM_P (op) && reg_mentioned_p (p->reg, op))
> +   {
> + unsigned int alignment = MEM_ALIGN (op);
> + if (alignment > *p->stack_alignment)
> +   *p->stack_alignment = alignment;
> + break;
> +   }
> +}
> +}
> +
> +/* Helper function for ix86_find_all_reg_use.  */
> +
> +static void
> +ix86_find_all_reg_use_1 (rtx set, HARD_REG_SET &stack_slot_access,
> +auto_bitmap &worklist)
> +{
> +  rtx dest = SET_DEST (set);
> +  if (!REG_P (dest))
> +return;
> +
> +  rtx src = SET_SRC (set);
> +
> +  if (GET_CODE (src) == ZERO_EXTEND)
> +src = XEXP (src, 0);
> +
> +  if (MEM_P (src) || CONST_SCALAR_INT_P (src))
> +return;
> +
> +  if (TEST_HARD_REG_BIT (stack_slot_access, REGNO (dest)))
> +return;
> +
> +  /* Add this register to stack_slot_access.  */
> +  add_to_hard_reg_set (&stack_slot_access, Pmode, REGNO (dest));
> +  bitmap_set_bit (worklist, REGNO (dest));
> +}

The above should also use FOR_EACH_SUBRTX iterators. Also, the
function will also record non-integer registers, such as flags_reg and
XMM registers as candidates. Please see the attached patch that
implements my proposed version.

> +
> +/* Find all registers defined with REG.  */
> +
> +static void
> +ix86_find_all_reg_use (HARD_REG_SET &stack_slot_access,
> +  unsigned int reg, auto_bitmap &worklist)
> +{
> +  for (df_ref ref = DF_REG_USE_CHAIN (reg);
> +   ref != NULL;
> +   ref = DF_REF_NEXT_REG (ref))

This will still record the whole chain of dependencies. This is firmly
on the safe side, but perhaps is a slight overkill. OTOH, my
implementation of ix86_find_all_reg_use_1 will reject all non-integer
registers, so let's keep it as is.

Can you please test the attached patch?

Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index d15f91ddd2c..288dc9d55ff 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -8473,6 +8473,116 @@ output_probe_stack_range (rtx reg, rtx end)
   return "";
 }
 
+/* 

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Jakub Jelinek]

On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek  wrote:
> >
> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> > > That's one option, but maybe it's better the other way round: instead of
> > > excluding known-bad targets, restrict cobol to known-good ones
> > > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
> > >
> > > I've been using the following for this (should be retested for safety).
> >
> > I admit I don't really know what works and what doesn't out of the box now,
> > but your patch looks reasonable to me for 15 branch.
> >
> > Richard, Robert and/or James, do you agree?
> 
> I agree to restrict =all to enable cobol only for known-good platform triples.
> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to allow

But libgcobol configure.tgt does it only for the target case.
Much more important right now is the host whitelist case.
The code in the FE is still not sufficiently portable and so even
i686-solaris -> x86_64-linux --enable-languages=all cross just won't build out
of the box (and even if it would, it wouldn't work properly).
Or x86_64-freebsd -> x86_64-linux might not either.

So, I think we want Rainer's patch here.

> a cobol build with explicit 'cobol' included even when configure.tgt claims
> unsupported?  So why's *-*solaris now included in =all?
> 
> I'm a bit confused, I thought we had =all restricted already.

> > > 2025-03-17  Rainer Orth  
> > >
> > >   PR cobol/119217
> > >   * configure.ac: Restrict cobol to aarch64-*-linux*,
> > >   x86_64-*-linux*.
> > >   * configure: Regenerate.

Jakub

Re: [PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

[Tomasz Kaminski]

On Fri, Apr 18, 2025 at 7:48 PM Luc Grosheintz 
wrote:

>
> On 4/18/25 2:00 PM, Tomasz Kaminski wrote:
> >
> >
> >
> > On Fri, Apr 18, 2025 at 1:43 PM Luc Grosheintz  > > wrote:
> >
> > This implements std::extents from  according to N4950 and
> > contains partial progress towards PR107761.
> >
> > If an extent changes its type, there's a precondition in the
> standard,
> > that the value is representable in the target integer type. This
> > precondition is not checked at runtime.
> >
> > The precondition for 'extents::{static_,}extent' is that '__r <
> rank()'.
> > For extents this precondition is always violated and results in
> > calling __builtin_trap. For all other specializations it's checked
> via
> > __glibcxx_assert.
> >
> >  PR libstdc++/107761
> >
> > libstdc++-v3/ChangeLog:
> >
> >  * include/std/mdspan (extents): New class.
> >  * src/c++23/std.cc.in : Add 'using
> > std::extents'.
> >
> > Signed-off-by: Luc Grosheintz  > >
> > ---
> >
> > LGTM.
> > Below, I shared one idea that I found interesting, and you could look
> into,
> > but not necessary.
> >
> >   libstdc++-v3/include/std/mdspan  | 249
> +++
> >   libstdc++-v3/src/c++23/std.cc.in  |   6 +-
> >   2 files changed, 254 insertions(+), 1 deletion(-)
> >
> > diff --git a/libstdc++-v3/include/std/mdspan b/libstdc++-v3/include/
> > std/mdspan
> > index 4094a416d1e..f7a47552485 100644
> > --- a/libstdc++-v3/include/std/mdspan
> > +++ b/libstdc++-v3/include/std/mdspan
> > @@ -33,6 +33,11 @@
> >   #pragma GCC system_header
> >   #endif
> >
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> >   #define __glibcxx_want_mdspan
> >   #include 
> >
> > @@ -41,6 +46,250 @@
> >   namespace std _GLIBCXX_VISIBILITY(default)
> >   {
> >   _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > +  namespace __mdspan
> > +  {
> > +template
> > +  class _ExtentsStorage
> > +  {
> > +  public:
> > +   static constexpr bool
> > +   _S_is_dyn(size_t __ext) noexcept
> > +   { return __ext == dynamic_extent; }
> > +
> > +   template
> > + static constexpr _IndexType
> > + _S_int_cast(const _OIndexType& __other) noexcept
> > + { return _IndexType(__other); }
> > +
> > +   static constexpr size_t _S_rank = _Extents.size();
> > +
> > +   // For __r in [0, _S_rank], _S_dynamic_index[__r] is the
> number
> > +   // of dynamic extents up to (and not including) __r.
> > +   //
> > +   // If __r is the index of a dynamic extent, then
> > +   // _S_dynamic_index[__r] is the index of that extent in
> > +   // _M_dynamic_extents.
> > +   static constexpr auto _S_dynamic_index = [] consteval
> > +   {
> > + array __ret;
> > + size_t __dyn = 0;
> > + for(size_t __i = 0; __i < _S_rank; ++__i)
> > +   {
> > + __ret[__i] = __dyn;
> > + __dyn += _S_is_dyn(_Extents[__i]);
> > +   }
> > + __ret[_S_rank] = __dyn;
> > + return __ret;
> > +   }();
> > +
> > +   static constexpr size_t _S_rank_dynamic =
> > _S_dynamic_index[_S_rank];
> > +
> > +   // For __r in [0, _S_rank_dynamic),
> > _S_dynamic_index_inv[__r] is the
> > +   // index of the __r-th dynamic extent in _Extents.
> > +   static constexpr auto _S_dynamic_index_inv = [] consteval
> > +   {
> > + array __ret;
> > + for (size_t __i = 0, __r = 0; __i < _S_rank; ++__i)
> > +   if (_S_is_dyn(_Extents[__i]))
> > + __ret[__r++] = __i;
> > + return __ret;
> > +   }();
> > +
> > +   static constexpr size_t
> > +   _S_static_extent(size_t __r) noexcept
> > +   { return _Extents[__r]; }
> > +
> > +   constexpr _IndexType
> > +   _M_extent(size_t __r) const noexcept
> > +   {
> > + auto __se = _Extents[__r];
> > + if (__se == dynamic_extent)
> > +   return _M_dynamic_extents[_S_dynamic_index[__r]];
> > + else
> > +   return __se;
> > +   }
> > +
> > +   template
> > + constexpr void
> > + _M_init_dynamic_extents(_GetOtherExtent __get_extent)
> noexcept
> > + {
> > +   for(size_t __i = 0; __i < _S_rank_dynamic; ++__i)
> > + {
> > +   size_t __di = __i;
> > +   if constexpr (_OtherRank != _S_rank_dynamic)
> > + __di = _S_dynamic_index_inv[__i];
> >

[PATCH] libstdc++: Update baseline symbols for riscv64-linux

[Andreas Schwab]

* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
---
 .../post/riscv64-linux-gnu/baseline_symbols.txt   | 15 +++
 1 file changed, 15 insertions(+)

diff --git 
a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
index 9229ad33458..7c2c19ba710 100644
--- a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
@@ -2124,6 +2124,10 @@ 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policy
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEaSEOS5_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
@@ -3221,6 +3225,8 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcm@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcm@@GLIBCXX_3.4.34
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3374,6 +3380,8 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEmw@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwm@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwm@@GLIBCXX_3.4.34
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3941,6 +3949,8 @@ 
FUNC:_ZNSt8__detail15_List_node_base11_M_transferEPS0_S1_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
+FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
+FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
 FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
@@ -4575,6 +4585,7 @@ OBJECT:0:CXXABI_1.3.12
 OBJECT:0:CXXABI_1.3.13
 OBJECT:0:CXXABI_1.3.14
 OBJECT:0:CXXABI_1.3.15
+OBJECT:0:CXXABI_1.3.16
 OBJECT:0:CXXABI_1.3.2
 OBJECT:0:CXXABI_1.3.3
 OBJECT:0:CXXABI_1.3.4
@@ -4612,6 +4623,7 @@ OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
 OBJECT:0:GLIBCXX_3.4.33
+OBJECT:0:GLIBCXX_3.4.34
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
@@ -4685,6 +4697,7 @@ OBJECT:15:_ZTSSt8numpunctIcE@@GLIBCXX_3.4
 OBJECT:15:_ZTSSt8numpunctIwE@@GLIBCXX_3.4
 OBJECT:16:_ZTIDF128_@@CXXABI_1.3.14
 OBJECT:16:_ZTIDF16_@@CXXABI_1.3.14
+OBJECT:16:_ZTIDF16b@@CXXABI_1.3.16
 OBJECT:16:_ZTIDF32_@@CXXABI_1.3.14
 OBJECT:16:_ZTIDF32x@@CXXABI_1.3.14
 OBJECT:16:_ZTIDF64_@@CXXABI_1.3.14
@@ -5327,6 +5340,7 @@ 
OBJECT:32:_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE@@GLIBCXX_3
 OBJECT:32:_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4
 OBJECT:32:_ZTIPDF128_@@CXXABI_1.3.14
 OBJECT:32:_ZTIPDF16_@@CXXABI_1.3.14
+OBJECT:32:_ZT

Re: [PATCH] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

[Jonathan Wakely]

On 22/04/25 09:38 +0200, Tomasz Kamiński wrote:

This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.

To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.

As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
* _CharT is constrained __formatter::__char
* basic_format_parse_context<_CharT> for parse argument
* basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.

Furthermore the standard specifies these formatters as delegating to
formatter, charT>, which in turn
delegates to range_formatter. This patch avoids one lever of indirection,


s/lever/level/


and dependency of ranges::ref_view.  This is technically observable if
user specializes formatter> where PD is program defined
container, but I do not think this is the case worth extra indirection.

This patch also moves the formattable and it's dependencies to the formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator>, to struct with type nested typedef
that points to same type, that is forward declared.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in declaration
in bits/formatfwd.h.
* include/std/queue (formatter, 
_CharT>)
(formatter, _CharT>): Define.
* include/std/stack (formatter, 
_CharT>):
Define.
* testsuite/std/format/ranges/adaptors.cc: New test.
---
I plan to update feature test macro in separate commit, after confirming that
everything is implemented. OK for trunk?

I think we need `__format::__char` constrain for thread::id, as we also
use friend to provide private acess. I plan to create commit that will
do that, and also change include to formatfwd.h.

libstdc++-v3/include/bits/formatfwd.h |  78 +
libstdc++-v3/include/bits/stl_queue.h |  14 ++
libstdc++-v3/include/bits/stl_stack.h |   9 +
libstdc++-v3/include/std/format   |  76 +
libstdc++-v3/include/std/queue|  74 +
libstdc++-v3/include/std/stack|  42 +
.../testsuite/std/format/ranges/adaptors.cc   | 156 ++
7 files changed, 381 insertions(+), 68 deletions(-)
create mode 100644 libstdc++-v3/testsuite/std/format/ranges/adaptors.cc

diff --git a/libstdc++-v3/include/bits/formatfwd.h 
b/libstdc++-v3/include/bits/formatfwd.h
index a6b5ac8c8ce..9ba658b078a 100644
--- a/libstdc++-v3/include/bits/formatfwd.h
+++ b/libstdc++-v3/include/bits/formatfwd.h
@@ -37,6 +37,12 @@
//  must have been included before this header:
#ifdef __glibcxx_format // C++ >= 20 && HOSTED

+#include 
+#include 
+#if __glibcxx_format_ranges // C++ >= 23 && HOSTED
+#  include   // input_range, range_reference_t
+#endif
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -50,6 +56,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  // [format.formatter], formatter
  template struct formatter;

+/// @cond undocumented
namespace __format
{
#ifdef _GLIBCXX_USE_WCHAR_T
@@ -60,9 +67,80 @@ namespace __format
concept __char = same_as<_CharT, char>;
#endif

+  template>,
+  typename _ParseContext
+= basic_format_parse_context>
+concept __parsable_with
+  = semiregular<_Formatter>
+ && requires (_Formatter __f, _ParseContext __pc)
+{
+  { __f.parse(__pc) } -> same_as;
+};
+
+  t

Re: [PATCH] libstdc++: Update baseline_symbols.txt for m68k-linux

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 10:25, Andreas Schwab wrote:
>
> * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.

OK for trunk and gcc-15 (confirmed by Jakub on IRC). Thanks.



> ---
>  .../abi/post/m68k-linux-gnu/baseline_symbols.txt  | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt 
> b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> index 675a9498724..089ae242a1b 100644
> --- a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> +++ b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> @@ -2124,6 +2124,10 @@ 
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policy
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
> +FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
>  FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
>  FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
>  FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
> @@ -3221,6 +3225,8 @@ 
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEjc@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj@@GLIBCXX_3.4.34
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcj@@GLIBCXX_3.4.34
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> @@ -3374,6 +3380,8 @@ 
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEjw@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwj@@GLIBCXX_3.4.34
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwj@@GLIBCXX_3.4.34
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> @@ -3941,6 +3949,8 @@ 
> FUNC:_ZNSt8__detail15_List_node_base11_M_transferEPS0_S1_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
> +FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
> +FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
>  FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
>  FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
>  FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
> @@ -4612,6 +4622,7 @@ OBJECT:0:GLIBCXX_3.4.30
>  OBJECT:0:GLIBCXX_3.4.31
>  OBJECT:0:GLIBCXX_3.4.32
>  OBJECT:0:GLIBCXX_3.4.33
> +OBJECT:0:GLIBCXX_3.4.34
>  OBJECT:0:GLIBCXX_3.4.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> --
> 2.49.0
>
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>

Re: [PATCH] libstdc++: Update baseline symbols for riscv64-linux

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 11:43, Andreas Schwab wrote:
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.

OK for trunk and gcc-15 (confirmed by Jakub on IRC).

> ---
>  .../post/riscv64-linux-gnu/baseline_symbols.txt   | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git 
> a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 
> b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
> index 9229ad33458..7c2c19ba710 100644
> --- a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
> +++ b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
> @@ -2124,6 +2124,10 @@ 
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policy
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC2EOS5_@@GLIBCXX_3.4.28
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC2Ev@@GLIBCXX_3.4.27
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEaSEOS5_@@GLIBCXX_3.4.26
> +FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
>  FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
>  FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
>  FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
> @@ -3221,6 +3225,8 @@ 
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcm@@GLIBCXX_3.4.34
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcm@@GLIBCXX_3.4.34
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> @@ -3374,6 +3380,8 @@ 
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEmw@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwm@@GLIBCXX_3.4.34
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwm@@GLIBCXX_3.4.34
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> @@ -3941,6 +3949,8 @@ 
> FUNC:_ZNSt8__detail15_List_node_base11_M_transferEPS0_S1_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
> +FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
> +FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
>  FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
>  FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
>  FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
> @@ -4575,6 +4585,7 @@ OBJECT:0:CXXABI_1.3.12
>  OBJECT:0:CXXABI_1.3.13
>  OBJECT:0:CXXABI_1.3.14
>  OBJECT:0:CXXABI_1.3.15
> +OBJECT:0:CXXABI_1.3.16
>  OBJECT:0:CXXABI_1.3.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4612,6 +4623,7 @@ OBJECT:0:GLIBCXX_3.4.30
>  OBJECT:0:GLIBCXX_3.4.31
>  OBJECT:0:GLIBCXX_3.4.32
>  OBJECT:0:GLIBCXX_3.4.33
> +OBJECT:0:GLIBCXX_3.4.34
>  OBJECT:0:GLIBCXX_3.4.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> @@ -4685,6 +4697,7 @@ OBJECT:15:_ZTSSt8numpunctIcE@@GLIBCXX_3.4
>  OBJECT:15:_ZTSSt8numpunctIwE@@GLIBCXX_3.4
>  OBJECT:16:_ZTIDF128_@@CXXABI_1.3.14
>  OBJECT:16:_ZTIDF16_@@CXXABI_1.3.14
> +OBJECT:16:_ZTIDF16b@@CXXABI_1.3.16
>  OBJECT:16:_ZTIDF32_@@CXXABI_1.3.14
>  OBJECT:16:_ZTIDF32x@@CXXABI_1.3.

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Richard Biener]

On Tue, Apr 22, 2025 at 12:31 PM Sam James  wrote:
>
> Jakub Jelinek  writes:
>
> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek  wrote:
> >> >
> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >> > > That's one option, but maybe it's better the other way round: instead 
> >> > > of
> >> > > excluding known-bad targets, restrict cobol to known-good ones
> >> > > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
> >> > >
> >> > > I've been using the following for this (should be retested for safety).
> >> >
> >> > I admit I don't really know what works and what doesn't out of the box 
> >> > now,
> >> > but your patch looks reasonable to me for 15 branch.
> >> >
> >> > Richard, Robert and/or James, do you agree?
> >>
> >> I agree to restrict =all to enable cobol only for known-good platform 
> >> triples.
> >> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to 
> >> allow
> >
> > But libgcobol configure.tgt does it only for the target case.
> > Much more important right now is the host whitelist case.
> > The code in the FE is still not sufficiently portable and so even
> > i686-solaris -> x86_64-linux --enable-languages=all cross just won't build 
> > out
> > of the box (and even if it would, it wouldn't work properly).
> > Or x86_64-freebsd -> x86_64-linux might not either.
> >
> > So, I think we want Rainer's patch here.
> >
>
> I thought about it further after discussion on IRC and I agree. Rainer's
> looks good.

OK, let's do that for GCC 15 then, we can add to the whilelist when we figure
additional known-good cases for 15.2.

Richard.

> >> a cobol build with explicit 'cobol' included even when configure.tgt claims
> >> unsupported?  So why's *-*solaris now included in =all?
> >>
> >> I'm a bit confused, I thought we had =all restricted already.
> >
> >> > > 2025-03-17  Rainer Orth  
> >> > >
> >> > >   PR cobol/119217
> >> > >   * configure.ac: Restrict cobol to aarch64-*-linux*,
> >> > >   x86_64-*-linux*.
> >> > >   * configure: Regenerate.
> >
> >   Jakub

Re: [PATCH] sanitizer: Store no_sanitize attribute value in uint32 instead of unsigned

[Sam James]

Kees Cook  writes:

> On Thu, Apr 10, 2025 at 05:17:51PM -0700, Keith Packard wrote:
>> A target using 16-bit ints won't have enough bits to hold the whole
>> flag_sanitize set. Be explicit about using uint32 for the attribute data.
>> 
>> Signed-off-by: Keith Packard 
>> ---
>>  gcc/c-family/c-attribs.cc | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
>> index 5a0e3d328ba..2a4ae10838a 100644
>> --- a/gcc/c-family/c-attribs.cc
>> +++ b/gcc/c-family/c-attribs.cc
>> @@ -1420,12 +1420,12 @@ add_no_sanitize_value (tree node, unsigned int flags)
>>if (flags == old_value)
>>  return;
>>  
>> -  TREE_VALUE (attr) = build_int_cst (unsigned_type_node, flags);
>> +  TREE_VALUE (attr) = build_int_cst (uint32_type_node, flags);
>>  }
>>else
>>  DECL_ATTRIBUTES (node)
>>= tree_cons (get_identifier ("no_sanitize"),
>> -   build_int_cst (unsigned_type_node, flags),
>> +   build_int_cst (uint32_type_node, flags),
>> DECL_ATTRIBUTES (node));
>>  }
>
> This looks correct to me. Martin, is this something you (or someone
> else) can get committed for GCC 15?

Martin isn't involved with GCC development anymore. But it's not clear
to me why this is critical for GCC 15. (Any further patches for 15.1
need to be both approved and then approved by release managers).

Did you need this for something on the Linux side?

More likely that if approved, it could then go into 15.2 which will be
in a few months (not a year unlike > X.3).

Re: [PATCH] libstdc++: Strip reference and cv-qual in range deduction guides for maps.

[Tomasz Kaminski]

The test cover constructors introduced in [PATCH v2] libstdc++-v3:
Implement missing allocator-aware constructors for unordered containers,
so I will merge that after.

On Fri, Apr 18, 2025 at 5:18 PM Jonathan Wakely 
wrote:

>
>
> On Fri, 18 Apr 2025, 12:55 Tomasz Kamiński,  wrote:
>
>> This implements part of LWG4223 that adjust the deduction guides for maps
>> types
>> (map, unordered_map, flat_map and non-unique equivalent) from "range",
>> such that
>> referience and cv qualification are stripped from the element of the
>> pair-like
>> value_type.
>>
>> In combination with r15-8296-gd50171bc07006d, the LWG4223 is fully
>> implemented now.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/bits/ranges_base.h (__detail::__range_key_type):
>> Replace remove_const_t with remove_cvref_t.
>> (__detail::__range_mapped_type): Apply remove_cvref_t.
>> * include/bits/stl_iterator.h: (__detail::__iter_key_t):
>> Replace remove_const_t with __remove_cvref_t.
>> (__detail::__iter_val_t): Apply __remove_cvref_t.
>> * testsuite/23_containers/flat_map/1.cc: New tests.
>> * testsuite/23_containers/flat_multimap/1.cc: New tests.
>> * testsuite/23_containers/map/cons/deduction.cc: New tests.
>> * testsuite/23_containers/map/cons/from_range.cc: New tests.
>> * testsuite/23_containers/multimap/cons/deduction.cc: New tests.
>> * testsuite/23_containers/multimap/cons/from_range.cc: New tests.
>> * testsuite/23_containers/unordered_map/cons/deduction.cc: New
>> tests.
>> * testsuite/23_containers/unordered_map/cons/from_range.cc: New
>> tests.
>> * testsuite/23_containers/unordered_multimap/cons/deduction.cc:
>> New tests.
>> * testsuite/23_containers/unordered_multimap/cons/from_range.cc:
>> New tests.
>> ---
>> Desipite there being some discussion about this on reflector, I think we
>> should go ahead with this, to avoid creating maps of references/const
>> types.
>> As we are at the begining of development of 16, this seems like a good
>> time
>> to do it.
>> OK for trunk?
>>
>
> OK for trunk.
>
>
>
>>
>>  libstdc++-v3/include/bits/ranges_base.h   |  4 +-
>>  libstdc++-v3/include/bits/stl_iterator.h  | 11 +--
>>  .../testsuite/23_containers/flat_map/1.cc | 21 +++---
>>  .../23_containers/flat_multimap/1.cc  | 21 +++---
>>  .../23_containers/map/cons/deduction.cc   | 46 +
>>  .../23_containers/map/cons/from_range.cc  |  8 +--
>>  .../23_containers/multimap/cons/deduction.cc  | 46 +
>>  .../23_containers/multimap/cons/from_range.cc |  8 +--
>>  .../unordered_map/cons/deduction.cc   | 69 +++
>>  .../unordered_map/cons/from_range.cc  | 10 ++-
>>  .../unordered_multimap/cons/deduction.cc  | 69 +++
>>  .../unordered_multimap/cons/from_range.cc | 10 +--
>>  12 files changed, 279 insertions(+), 44 deletions(-)
>>
>> diff --git a/libstdc++-v3/include/bits/ranges_base.h
>> b/libstdc++-v3/include/bits/ranges_base.h
>> index 488907da446..dde16498856 100644
>> --- a/libstdc++-v3/include/bits/ranges_base.h
>> +++ b/libstdc++-v3/include/bits/ranges_base.h
>> @@ -1103,11 +1103,11 @@ namespace __detail
>>// 4223. Deduction guides for maps are mishandling tuples and
>> references
>>template
>>  using __range_key_type
>> -  = remove_const_t> ranges::range_value_t<_Range>>>;
>> +  = remove_cvref_t> ranges::range_value_t<_Range>>>;
>>
>>template
>>  using __range_mapped_type
>> -  = tuple_element_t<1, ranges::range_value_t<_Range>>;
>> +  = remove_cvref_t> ranges::range_value_t<_Range>>>;
>>
>>// The allocator's value_type for map-like containers.
>>template
>> diff --git a/libstdc++-v3/include/bits/stl_iterator.h
>> b/libstdc++-v3/include/bits/stl_iterator.h
>> index 9203a66b2ff..bed72955d0c 100644
>> --- a/libstdc++-v3/include/bits/stl_iterator.h
>> +++ b/libstdc++-v3/include/bits/stl_iterator.h
>> @@ -3086,8 +3086,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>  #if __cpp_deduction_guides >= 201606
>>// These helper traits are used for deduction guides
>>// of associative containers.
>> +
>> +  // _GLIBCXX_RESOLVE_LIB_DEFECTS
>> +  // 4223. Deduction guides for maps are mishandling tuples and
>> references
>>template
>> -using __iter_key_t = remove_const_t<
>> +using __iter_key_t = __remove_cvref_t<
>>  #ifdef __glibcxx_tuple_like // >= C++23
>>tuple_element_t<0, typename
>> iterator_traits<_InputIterator>::value_type>>;
>>  #else
>> @@ -3095,11 +3098,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>  #endif
>>
>>template
>> -using __iter_val_t
>> +using __iter_val_t = __remove_cvref_t<
>>  #ifdef __glibcxx_tuple_like // >= C++23
>> -  = tuple_element_t<1, typename
>> iterator_traits<_InputIterator>::value_type>;
>> +  tuple_element_t<1, typename
>> iterator_traits<_InputIterator>::value_type>>;
>>  #else
>> -  = typ

Re: [PATCH 1/2] icf: Remove nop code from sem_function::init.

[Martin Jambor]

Hi,

On Thu, Apr 17 2025, Andrew Pinski wrote:
> Here we had:
>   node = node;
> Which does nothing so let's remove it.
>
> gcc/ChangeLog:
>
>   * ipa-icf.cc (sem_function::init): Remove assignment of node from 
> itself.

I'm not sure if you meant to push this as obvious or whether you were
looking for an approval.  In the latter case, please go ahead and commit
the patch.

Thanks,

Martin


>
> Signed-off-by: Andrew Pinski 
> ---
>  gcc/ipa-icf.cc | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
> index 3fccc620a82..c273032cae2 100644
> --- a/gcc/ipa-icf.cc
> +++ b/gcc/ipa-icf.cc
> @@ -1367,7 +1367,6 @@ sem_function::init (ipa_icf_gimple::func_checker 
> *checker)
>gcc_assert (SSANAMES (func));
>  
>ssa_names_size = SSANAMES (func)->length ();
> -  node = node;
>  
>decl = fndecl;
>region_tree = func->eh->region_tree;
> -- 
> 2.43.0

Re: [PATCH 1/2] icf: Remove nop code from sem_function::init.

[Andrew Pinski]

On Tue, Apr 22, 2025 at 12:11 AM Martin Jambor  wrote:
>
> Hi,
>
> On Thu, Apr 17 2025, Andrew Pinski wrote:
> > Here we had:
> >   node = node;
> > Which does nothing so let's remove it.
> >
> > gcc/ChangeLog:
> >
> >   * ipa-icf.cc (sem_function::init): Remove assignment of node from 
> > itself.
>
> I'm not sure if you meant to push this as obvious or whether you were
> looking for an approval.  In the latter case, please go ahead and commit
> the patch.

I was looking for approval since I was not 100% sure I was not missing
something. Note I am going to wait until GCC 15.1.0 is out the door
before pushing this one.

Thanks,
Andrew Pinski

>
> Thanks,
>
> Martin
>
>
> >
> > Signed-off-by: Andrew Pinski 
> > ---
> >  gcc/ipa-icf.cc | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
> > index 3fccc620a82..c273032cae2 100644
> > --- a/gcc/ipa-icf.cc
> > +++ b/gcc/ipa-icf.cc
> > @@ -1367,7 +1367,6 @@ sem_function::init (ipa_icf_gimple::func_checker 
> > *checker)
> >gcc_assert (SSANAMES (func));
> >
> >ssa_names_size = SSANAMES (func)->length ();
> > -  node = node;
> >
> >decl = fndecl;
> >region_tree = func->eh->region_tree;
> > --
> > 2.43.0

Re: [PATCH] gimple: Canonical order for invariants [PR118902]

[Richard Biener]

On Tue, Apr 22, 2025 at 1:06 AM Andrew Pinski  wrote:
>
> On Mon, Apr 21, 2025 at 1:42 AM Richard Biener
>  wrote:
> >
> > On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski  
> > wrote:
> > >
> > > So unlike constants, address invariants are currently put first if
> > > used with a SSA NAME.
> > > It would be better if address invariants are consistent with constants
> > > and this patch changes that.
> > > gcc.dg/tree-ssa/pr118902-1.c is an example where this canonicalization
> > > can help. In it if `p` variable was a global variable, FRE (VN) would 
> > > have figured
> > > it out that `a` could never be equal to `&p` inside the loop. But without 
> > > the
> > > canonicalization we end up with `&p == a.0_1` which VN does try to handle 
> > > for conditional
> > > VN.
> > >
> > > Bootstrapped and tested on x86_64.
> > >
> > > PR tree-optimization/118902
> > > gcc/ChangeLog:
> > >
> > > * fold-const.cc (tree_swap_operands_p): Place invariants in the 
> > > first operand
> > > if not used with constants.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * gcc.dg/tree-ssa/pr118902-1.c: New test.
> > >
> > > Signed-off-by: Andrew Pinski 
> > > ---
> > >  gcc/fold-const.cc  |  6 ++
> > >  gcc/testsuite/gcc.dg/tree-ssa/pr118902-1.c | 21 +
> > >  2 files changed, 27 insertions(+)
> > >  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr118902-1.c
> > >
> > > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> > > index 1275ef75315..c9471ea44b0 100644
> > > --- a/gcc/fold-const.cc
> > > +++ b/gcc/fold-const.cc
> > > @@ -7246,6 +7246,12 @@ tree_swap_operands_p (const_tree arg0, const_tree 
> > > arg1)
> > >if (TREE_CONSTANT (arg0))
> > >  return true;
> > >
> > > +  /* Put invariant address in arg1. */
> > > +  if (is_gimple_invariant_address (arg1))
> > > +return false;
> > > +  if (is_gimple_invariant_address (arg0))
> > > +return true;
> >
> > We could make this cheaper by considering all ADDR_EXPRs here?
>
> Maybe. we should.
>
> >
> > I'll note that with this or the above
> >
> >   /* Put SSA_NAMEs last.  */
> >   if (TREE_CODE (arg1) == SSA_NAME)
> > return false;
> >   if (TREE_CODE (arg0) == SSA_NAME)
> > return true;
> >
> > is a bit redundant and contradicting, when we are in GIMPLE, at least.
> > I'd say on GIMPLE reversing the above to put SSA_NAMEs first would
> > solve the ADDR_EXPR issue as well.
> >
> > The idea of tree_swap_operands_p seems to be to put "simple" things
> > second, but on GIMPLE SSA_NAME is not simple.  With GENERIC
> > this would put memory refs first, SSA_NAME second, which is reasonable.
>
>
> So looking into the history on this. I find this from you from 2007:
> https://inbox.sourceware.org/gcc-patches/pine.lnx.4.64.0702161440530.18...@zhemvz.fhfr.qr/

Likely fold_comparison and friends was just testing one variant,
possibly match.pd does better and correctly uses :c there.

Note in principle a SSA name is a sub-expression while a DECL is memory,
so while the change probably fixed some missed folding the reasoning seems
wrong.

> I do wonder if we need a better way of describing the difference
> between gimple and generic too.

It might be tempting to split the predicate into a GIMPLE and GENERIC
variant ... but I'm not sure that for example gimplification re-canonicalizes
upon GIMPLE building.

> >
> > I'd say since an ADDR_EXPR is always a "value" (not memory), putting it
> > last makes sense in general, whether invariant or not.  Can you test that?
> > The issue with is_gimple_invariant_address is that it walks all handled
> > components.
>
> Yes I will try to make that change to see if that fixes the issue; I
> think it does. Note `&a[var]` is not simple but will be treated as
> such with having ADDR_EXPR here; the walk figures out if it is simple
> or not though.

Yeah, that mostly makes a difference on GENERIC though since on GIMPLE
all ADDR_EXPR operands are simple, &a[var] would be a separate SSA def.
The difference might be for &decl with some specific decls that are not IP
invariant.

Richard.

>
> Thanks,
> Andrew Pinski
>
>
> >
> > Richard.
> >
> > > +
> > >/* It is preferable to swap two SSA_NAME to ensure a canonical form
> > >   for commutative and comparison operators.  Ensuring a canonical
> > >   form allows the optimizers to find additional redundancies without
> > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr118902-1.c 
> > > b/gcc/testsuite/gcc.dg/tree-ssa/pr118902-1.c
> > > new file mode 100644
> > > index 000..fa21b8a74ef
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr118902-1.c
> > > @@ -0,0 +1,21 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> > > +
> > > +void foo(int);
> > > +void l(int**);
> > > +int f1(int j, int t)
> > > +{
> > > +  int p = 0;
> > > +  int *a = &p;
> > > +  l(&a);
> > > +  if (a == &p)
> > > +return 0;
> > > +  for(int i = 0; i < j; i++)
> > > +

Re: [PATCH 2/2] icf: Remove unused constructors of sem_function and sem_variable

[Martin Jambor]

Hi,

On Thu, Apr 17 2025, Andrew Pinski wrote:
> The constructors for sem_function and sem_variable that just
> passes the bitmap obstack and NOT the cgraph node was unused
> so let's remove it.
>
> gcc/ChangeLog:
>
>   * ipa-icf.cc (sem_function::sem_function): Remove
>   the obstack argument version one.
>   (sem_variable::sem_variable): Likewise.
>   * ipa-icf.h (sem_function): Remove ctor for
>   obstack argument only one.
>   (sem_variable): Likewise.
>

Likewise, I'm not sure if you meant to push this as obvious or whether
you were looking for an approval.  In the latter case, please go ahead
and commit the patch.

Thanks,

Martin


> Signed-off-by: Andrew Pinski 
> ---
>  gcc/ipa-icf.cc | 14 --
>  gcc/ipa-icf.h  |  5 -
>  2 files changed, 19 deletions(-)
>
> diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
> index c273032cae2..b354fb1e704 100644
> --- a/gcc/ipa-icf.cc
> +++ b/gcc/ipa-icf.cc
> @@ -233,16 +233,6 @@ void sem_item::set_hash (hashval_t hash)
>  
>  hash_map sem_item::m_type_hash_cache;
>  
> -/* Semantic function constructor that uses STACK as bitmap memory stack.  */
> -
> -sem_function::sem_function (bitmap_obstack *stack)
> -  : sem_item (FUNC, stack), memory_access_types (), m_alias_sets_hash (0),
> -m_checker (NULL), m_compared_func (NULL)
> -{
> -  bb_sizes.create (0);
> -  bb_sorted.create (0);
> -}
> -
>  sem_function::sem_function (cgraph_node *node, bitmap_obstack *stack)
>: sem_item (FUNC, node, stack), memory_access_types (),
>  m_alias_sets_hash (0), m_checker (NULL), m_compared_func (NULL)
> @@ -1646,10 +1636,6 @@ sem_function::bb_dict_test (vec *bb_dict, int 
> source, int target)
>  return (*bb_dict)[source] == target;
>  }
>  
> -sem_variable::sem_variable (bitmap_obstack *stack): sem_item (VAR, stack)
> -{
> -}
> -
>  sem_variable::sem_variable (varpool_node *node, bitmap_obstack *stack)
>  : sem_item (VAR, node, stack)
>  {
> diff --git a/gcc/ipa-icf.h b/gcc/ipa-icf.h
> index c2854ed4496..4c9094c1950 100644
> --- a/gcc/ipa-icf.h
> +++ b/gcc/ipa-icf.h
> @@ -308,8 +308,6 @@ private:
>  class sem_function: public sem_item
>  {
>  public:
> -  /* Semantic function constructor that uses STACK as bitmap memory stack.  
> */
> -  sem_function (bitmap_obstack *stack);
>  
>/*  Constructor based on callgraph node _NODE.
>Bitmap STACK is used for memory allocation.  */
> @@ -419,9 +417,6 @@ private:
>  class sem_variable: public sem_item
>  {
>  public:
> -  /* Semantic variable constructor that uses STACK as bitmap memory stack.  
> */
> -  sem_variable (bitmap_obstack *stack);
> -
>/*  Constructor based on callgraph node _NODE.
>Bitmap STACK is used for memory allocation.  */
>  
> -- 
> 2.43.0

[PATCH] libstdc++: Update Solaris baselines for GCC 15.1

[Rainer Orth]

This patch updates the Solaris libstdc++ baselines for GCC 15.1.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
gcc-15 branch and trunk.

Ok for both?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2025-02-11  Rainer Orth  

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

# HG changeset patch
# Parent  6d7791b075990b10e917244f0ee651f4bce5e6e6
libstdc++: Update Solaris baselines for GCC 15.0

diff --git a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
@@ -2095,6 +2095,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
@@ -3182,6 +3186,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcm@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcm@@GLIBCXX_3.4.34
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3335,6 +3341,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEmw@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwm@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwm@@GLIBCXX_3.4.34
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3902,6 +3910,8 @@ FUNC:_ZNSt8__detail15_List_node_base11_M
 FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
+FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
+FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
 FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
@@ -4571,6 +4581,7 @@ OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
 OBJECT:0:GLIBCXX_3.4.33
+OBJECT:0:GLIBCXX_3.4.34
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
diff --git a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
@@ -2095,6 +2095,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
 FUNC:_ZNSt

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

[Rainer Orth]

Hi Jonathan,

> On Tue, 22 Apr 2025 at 09:47, Rainer Orth  
> wrote:
>>
>> Hi Jonathan,
>>
>> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth 
>> > wrote:
>> >>
>> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
>> >> This patch fixes that.
>> >>
>> >> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>> >>
>> >> Ok for both?
>> >
>> > This adds:
>> >
>> > +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
>> > +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
>> >
>> > For the other linux targets we don't include those in the baselines.
>>
>> ah, I missed that.  Patch adjusted accordingly and retested.
>
> Thanks - everything else looks as expected, so OK for trunk and gcc-15.

Thanks.  For the avoidance of doubt: Jakub, Richard, I guess this is ok
for the gcc-15 branch, too?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 11:32:43AM +0200, Rainer Orth wrote:
> Hi Jonathan,
> 
> > On Tue, 22 Apr 2025 at 09:47, Rainer Orth  
> > wrote:
> >>
> >> Hi Jonathan,
> >>
> >> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth 
> >> > wrote:
> >> >>
> >> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> >> >> This patch fixes that.
> >> >>
> >> >> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
> >> >>
> >> >> Ok for both?
> >> >
> >> > This adds:
> >> >
> >> > +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> >> > +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> >> >
> >> > For the other linux targets we don't include those in the baselines.
> >>
> >> ah, I missed that.  Patch adjusted accordingly and retested.
> >
> > Thanks - everything else looks as expected, so OK for trunk and gcc-15.
> 
> Thanks.  For the avoidance of doubt: Jakub, Richard, I guess this is ok
> for the gcc-15 branch, too?

Yes.

Jakub

Re: [PATCH] libstdc++: Increase timeouts for format and flat_maps tests

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 10:03, Tomasz Kamiński  wrote:
>
> Test for format parse format string and compile time,
> flat_maps ones test all functionality in single test file.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/23_containers/flat_map/1.cc: Add dg-timeout-factor 2.
> * testsuite/23_containers/flat_multimap/1.cc: Likewise.
> * testsuite/std/format/ranges/map.cc: Likewise.
> * testsuite/std/format/ranges/sequence.cc: Likewise.
> * testsuite/std/format/ranges/string.cc: Likewise.
> ---
> This makes the test pass with timeout set for 60s (used for the .gnurc file
> that we use for compiler farm). OK for turnk?

OK, thanks.


>
>  libstdc++-v3/testsuite/23_containers/flat_map/1.cc  | 1 +
>  libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc | 1 +
>  libstdc++-v3/testsuite/std/format/ranges/map.cc | 1 +
>  libstdc++-v3/testsuite/std/format/ranges/sequence.cc| 1 +
>  libstdc++-v3/testsuite/std/format/ranges/string.cc  | 1 +
>  5 files changed, 5 insertions(+)
>
> diff --git a/libstdc++-v3/testsuite/23_containers/flat_map/1.cc 
> b/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
> index d9d88c4df6e..4fd33f616f7 100644
> --- a/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
> +++ b/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
> @@ -1,4 +1,5 @@
>  // { dg-do run { target c++23 } }
> +// { dg-timeout-factor 2 }
>
>  #include 
>
> diff --git a/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc 
> b/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
> index ff180bf1bdf..ea0d4b41e9f 100644
> --- a/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
> +++ b/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
> @@ -1,4 +1,5 @@
>  // { dg-do run { target c++23 } }
> +// { dg-timeout-factor 2 }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/std/format/ranges/map.cc 
> b/libstdc++-v3/testsuite/std/format/ranges/map.cc
> index 34c5ed554b8..1838480e2cf 100644
> --- a/libstdc++-v3/testsuite/std/format/ranges/map.cc
> +++ b/libstdc++-v3/testsuite/std/format/ranges/map.cc
> @@ -1,4 +1,5 @@
>  // { dg-do run { target c++23 } }
> +// { dg-timeout-factor 2 }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/std/format/ranges/sequence.cc 
> b/libstdc++-v3/testsuite/std/format/ranges/sequence.cc
> index 61fc68ea252..f05f6ec1e1c 100644
> --- a/libstdc++-v3/testsuite/std/format/ranges/sequence.cc
> +++ b/libstdc++-v3/testsuite/std/format/ranges/sequence.cc
> @@ -1,4 +1,5 @@
>  // { dg-do run { target c++23 } }
> +// { dg-timeout-factor 2 }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/std/format/ranges/string.cc 
> b/libstdc++-v3/testsuite/std/format/ranges/string.cc
> index 7f59f59dda3..cf39aa66e07 100644
> --- a/libstdc++-v3/testsuite/std/format/ranges/string.cc
> +++ b/libstdc++-v3/testsuite/std/format/ranges/string.cc
> @@ -1,4 +1,5 @@
>  // { dg-do run { target c++23 } }
> +// { dg-timeout-factor 2 }
>
>  #include 
>  #include 
> --
> 2.49.0
>

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 09:47, Rainer Orth  wrote:
>
> Hi Jonathan,
>
> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth  
> > wrote:
> >>
> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> >> This patch fixes that.
> >>
> >> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
> >>
> >> Ok for both?
> >
> > This adds:
> >
> > +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> > +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> >
> > For the other linux targets we don't include those in the baselines.
>
> ah, I missed that.  Patch adjusted accordingly and retested.

Thanks - everything else looks as expected, so OK for trunk and gcc-15.

Re: [PATCH] Add COBOL to htdocs/gcc-15/changes.html.

[Gerald Pfeifer]

On Thu, 17 Apr 2025, Robert Dubner wrote:
> Adds a COBOL section to htdocs/gcc-15/changes.html.

There was an extra  in there which I just fixed (= pushed).

(The first hunk is just a whitespace change to align more closely with the 
rest of the page; the fix is in the second hunk.)

Gerald


commit d2006521b0de11d4df49a7c5901740c555d49a68
Author: Gerald Pfeifer 
Date:   Tue Apr 22 11:09:36 2025 +0200

gcc-15: Fix markup

diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index b94802f5..f03e29c8 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -162,8 +162,9 @@ a work-in-progress.
 omp_get_uid_from_device API routines have been added.
   
 
+
 COBOL
-
+
   GCC now includes an ISO COBOL compiler, gcobol.  It has been
 tested on x86-64 and AArch64 targets. It is not expected to work
 on 32-bit systems. Efforts are underway to adapt it to other machine
@@ -175,8 +176,7 @@ a work-in-progress.
 ISO, gcobol recognizes some syntax common on other compilers,
 with special attention given to IBM.
More information about GCC COBOL can be found at
-   https://www.cobolworx.com";>the COBOLworx website.
-
+   https://www.cobolworx.com";>the COBOLworx website.
  
 
 Ada

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64, i486, powerpc64le, s390x, aarch64}-linux

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 09:49, Jakub Jelinek  wrote:
>
> On Tue, Apr 22, 2025 at 09:29:16AM +0100, Jonathan Wakely wrote:
> > On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek  wrote:
> > > We forgot to update these timely, sorry for that, the following patch
> > > updates them from the 15.1-rc1 builds in Fedora.
> > >
> > > Ok for trunk and 15?
> > >
> > > 2025-04-22  Jakub Jelinek  
> > >
> > > * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> > > * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: 
> > > Update.
> > > * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> > > * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> > > * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> > > * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: 
> > > Update.
> > >
> > > --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj 
> > >   2024-04-11 16:37:22.625001351 +0200
> > > +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> > > 2025-04-22 09:52:38.360802666 +0200
> > > @@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
> > >  
> > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
> > >  
> > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
> > >  
> > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
> > > +FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
> > > +FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
> > > +FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
> > > +FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
> >
> > I'm curious where these come from, and why they are present now but
> > weren't needed before.
>
> Are you going to investigate or should I?
> Note, Rainer has it in his patches as well.

I realised where it comes from and posted a second reply shortly after
the first. The patches are approved - thanks!

[PATCH] libstdc++: Update baseline_symbols.txt for m68k-linux

[Andreas Schwab]

* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
---
 .../abi/post/m68k-linux-gnu/baseline_symbols.txt  | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
index 675a9498724..089ae242a1b 100644
--- a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
@@ -2124,6 +2124,10 @@ 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policy
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
+FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
@@ -3221,6 +3225,8 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEjc@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcj@@GLIBCXX_3.4.34
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3374,6 +3380,8 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEjw@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwj@@GLIBCXX_3.4.34
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwj@@GLIBCXX_3.4.34
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -3941,6 +3949,8 @@ 
FUNC:_ZNSt8__detail15_List_node_base11_M_transferEPS0_S1_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
 FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
+FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
+FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
 FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
@@ -4612,6 +4622,7 @@ OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
 OBJECT:0:GLIBCXX_3.4.33
+OBJECT:0:GLIBCXX_3.4.34
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
-- 
2.49.0


-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 15.1

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 09:18:14AM +0200, Rainer Orth wrote:
> This patch updates the Solaris libstdc++ baselines for GCC 15.1.
> 
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
> gcc-15 branch and trunk.
> 
> Ok for both?
> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2025-02-11  Rainer Orth  
> 
>   libstdc++-v3:
>   * config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
>   * config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
>   Likewise.
>   * config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
>   * config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
>   Likewise.

This matches the changes I've posted for linux targets; if
Jonathan approves this, it is ok for 15 branch too.

Jakub

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Jakub Jelinek]

On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote:
> Sam James  writes:
> 
> > Richard Biener  writes:
> >
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek  wrote:
> >>>
> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >>> > That's one option, but maybe it's better the other way round: instead of
> >>> > excluding known-bad targets, restrict cobol to known-good ones
> >>> > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
> >>> >
> >>> > I've been using the following for this (should be retested for safety).
> >>>
> >>> I admit I don't really know what works and what doesn't out of the box 
> >>> now,
> >>> but your patch looks reasonable to me for 15 branch.
> >>>
> >>> Richard, Robert and/or James, do you agree?
> >>
> >> I agree to restrict =all to enable cobol only for known-good platform 
> >> triples.
> >> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to 
> >> allow
> >> a cobol build with explicit 'cobol' included even when configure.tgt claims
> >> unsupported?  So why's *-*solaris now included in =all?
> >>
> >> I'm a bit confused, I thought we had =all restricted already.
> >
> > Think we may be missing some wiring.
> >
> > # Always enable COBOL for --enable-languages=*cobol*
> > # Otherwise, enable COBOL only for known architectures
> > case ,${enable_languages}, in
> > [...]
> >   *)
> > case "${target}" in
> >   *-*-darwin*)
> > unsupported_languages="$unsupported_languages cobol"
> > ;;
> >   x86_64-*-*|aarch64-*-*)
> > ;;
> >   *-*-*)
> > unsupported_languages="$unsupported_languages cobol"
> > ;;
> > esac
> > [... ditto ${host} ...]
> >
> > We don't seem to ever add cobol to unsupported_languages if we added
> > target-libgcobol to noconfigdirs.
> >
> > The earlier check for libgcobol being supported does match other runtime
> > libraries but the only other *language-specific* runtime library it
> > matches is libphobos, where D supports a minimal build without that, so
> > it doesn't cater for this.
> 
> so, untested simple:
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -768,6 +768,7 @@ if test -d ${srcdir}/libgcobol; then
>   then
>   AC_MSG_RESULT([no])
>   noconfigdirs="$noconfigdirs target-libgcobol"
> + unsupported_languages="$unsupported_languages cobol"
>   else
>   AC_MSG_RESULT([yes])
>   fi
> 
> may do it for now. It still allows forcing libgcobol build with
> --enable-libgcobol. But if doing --enable-languages=cobol, you'd need
> --enable-libgcobol as well (but no idea if we really have tested cobol
> w/o libgcobol at all yet, or what).

I think we don't do this for any other language, do we?
Sure, if one only configures a library and does not enable the language,
the library is quite useless, and if one only configures the language and
the library is not configured, one can only compile code written in that
language but can't link it nor run it.  E.g. for i686-linux (no multilib)
libgcobol is not UNSUPPORTED at the toplevel and so --enable-languages=all,cobol
at least we still build the FE but libgcobol is configured but doesn't build
anything.
So, the unsupported_languages="$unsupported_languages cobol" should IMHO be
more about on which triplets it is known not to build the FE or have similar
major issues with it.
And to be honest, i686-linux is one of them, my patch to avoid depending on
size_t being unsigned long int is not in, so there will be at least many
warnings.
So the previous patch made more sense to me.

Jakub

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Sam James]

Jakub Jelinek  writes:

> On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote:
>> Sam James  writes:
>> 
>> > Richard Biener  writes:
>> >
>> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek  wrote:
>> >>>
>> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> >>> > That's one option, but maybe it's better the other way round: instead 
>> >>> > of
>> >>> > excluding known-bad targets, restrict cobol to known-good ones
>> >>> > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
>> >>> >
>> >>> > I've been using the following for this (should be retested for safety).
>> >>>
>> >>> I admit I don't really know what works and what doesn't out of the box 
>> >>> now,
>> >>> but your patch looks reasonable to me for 15 branch.
>> >>>
>> >>> Richard, Robert and/or James, do you agree?
>> >>
>> >> I agree to restrict =all to enable cobol only for known-good platform 
>> >> triples.
>> >> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to 
>> >> allow
>> >> a cobol build with explicit 'cobol' included even when configure.tgt 
>> >> claims
>> >> unsupported?  So why's *-*solaris now included in =all?
>> >>
>> >> I'm a bit confused, I thought we had =all restricted already.
>> >
>> > Think we may be missing some wiring.
>> >
>> > # Always enable COBOL for --enable-languages=*cobol*
>> > # Otherwise, enable COBOL only for known architectures
>> > case ,${enable_languages}, in
>> > [...]
>> >   *)
>> > case "${target}" in
>> >   *-*-darwin*)
>> > unsupported_languages="$unsupported_languages cobol"
>> > ;;
>> >   x86_64-*-*|aarch64-*-*)
>> > ;;
>> >   *-*-*)
>> > unsupported_languages="$unsupported_languages cobol"
>> > ;;
>> > esac
>> > [... ditto ${host} ...]
>> >
>> > We don't seem to ever add cobol to unsupported_languages if we added
>> > target-libgcobol to noconfigdirs.
>> >
>> > The earlier check for libgcobol being supported does match other runtime
>> > libraries but the only other *language-specific* runtime library it
>> > matches is libphobos, where D supports a minimal build without that, so
>> > it doesn't cater for this.
>> 
>> so, untested simple:
>> 
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -768,6 +768,7 @@ if test -d ${srcdir}/libgcobol; then
>>  then
>>  AC_MSG_RESULT([no])
>>  noconfigdirs="$noconfigdirs target-libgcobol"
>> +unsupported_languages="$unsupported_languages cobol"
>>  else
>>  AC_MSG_RESULT([yes])
>>  fi
>> 
>> may do it for now. It still allows forcing libgcobol build with
>> --enable-libgcobol. But if doing --enable-languages=cobol, you'd need
>> --enable-libgcobol as well (but no idea if we really have tested cobol
>> w/o libgcobol at all yet, or what).
>
> I think we don't do this for any other language, do we?

We don't have any other languages needing a whitelist for the FE itself,
though - just target libraries (libada, phobos, etc).

> Sure, if one only configures a library and does not enable the language,
> the library is quite useless, and if one only configures the language and
> the library is not configured, one can only compile code written in that
> language but can't link it nor run it.  E.g. for i686-linux (no multilib)
> libgcobol is not UNSUPPORTED at the toplevel and so 
> --enable-languages=all,cobol
> at least we still build the FE but libgcobol is configured but doesn't build
> anything.
> So, the unsupported_languages="$unsupported_languages cobol" should IMHO be
> more about on which triplets it is known not to build the FE or have similar
> major issues with it.
> And to be honest, i686-linux is one of them, my patch to avoid depending on
> size_t being unsigned long int is not in, so there will be at least many
> warnings.
> So the previous patch made more sense to me.
>

My concern with that is it's still not the whitelist approach and we may
well get reports of --enable-languages=all regressing on FreeBSD or some
other target we didn't look at. OTOH, it has an easy workaround, and
further fixes will surely be backported to 15.2. So, your
https://inbox.sourceware.org/gcc-patches/aAJmt2ju0QXChcXI@tucnak/ WFM
too. Either way will work.

sam

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64, i486, powerpc64le, s390x, aarch64}-linux

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek  wrote:
>
> Hi!
>
> We forgot to update these timely, sorry for that, the following patch
> updates them from the 15.1-rc1 builds in Fedora.
>
> Ok for trunk and 15?
>
> 2025-04-22  Jakub Jelinek  
>
> * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
> * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
>
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj 
>   2024-04-11 16:37:22.625001351 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> 2025-04-22 09:52:38.360802666 +0200
> @@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
>  
> FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
> +FUNC:_ZNSt12__sso_stringC1Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringC2Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringD1Ev@@GLIBCXX_3.4.34
> +FUNC:_ZNSt12__sso_stringD2Ev@@GLIBCXX_3.4.34

I'm curious where these come from, and why they are present now but
weren't needed before.

>  FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
>  FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
>  FUNC:_ZNSt12bad_weak_ptrD2Ev@@GLIBCXX_3.4.15
> @@ -3221,6 +3225,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcm@@GLIBCXX_3.4.34
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcm@@GLIBCXX_3.4.34
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> @@ -3374,6 +3380,8 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructEmw@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwm@@GLIBCXX_3.4.34
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwm@@GLIBCXX_3.4.34
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKwS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPwS4_vT_SA_St20forward_iterator_tag@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag@@GLIBCXX_3.4.21
> @@ -3941,6 +3949,8 @@ FUNC:_ZNSt8__detail15_List_node_base11_M
>  FUNC:_ZNSt8__detail15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base7_M_hookEPS0_@@GLIBCXX_3.4.15
>  FUNC:_ZNSt8__detail15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.15
> +FUNC:_ZNSt8__format25__locale_encoding_to_utf8ERKSt6localeSt17basic_string_viewIcSt11char_traitsIcEEPv@@GLIBCXX_3.4.34
> +FUNC:_ZNSt8__format26__with_encoding_conversionERKSt6locale@@GLIBCXX_3.4.34
>  FUNC:_ZNSt8bad_castD0Ev@@GLIBCXX_3.4
>  FUNC:_ZNSt8bad_castD1Ev@@GLIBCXX_3.4
>  FUNC:_ZNSt8bad_castD2Ev@@GLIBCXX_3.4
> @@ -4617,6 +4627,7 @@ OBJECT:0:GLIBCXX_3.4.30
>  OBJECT:0:GLIBCXX_3.4.31
>  OBJECT:0:GLIBCXX_3.4.32
>  OBJECT:0:GLIBCXX_3.4.33
> +OBJECT:0:GLIBCXX_3.4.34
>  OBJECT:0:GLIBCXX_3.4.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj  
>   2024-04-11 16:37:22.627001324 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt 
>   2025-04-22 09:52:51.946619578 +0200
> @@ -2124,6 +2124,10 @@ FUNC:_ZNSt12__shared_ptrINSt10filesystem
>  
> F

Re: [PATCH v2 1/3] RISC-V: Combine vec_duplicate + vadd.vv to vadd.vx on GR2VR cost

[Robin Dapp]

   /* TODO: We set RVV instruction cost as 1 by default.
  Cost Model need to be well analyzed and supported in the future. */
+  int cost_val = 1;
+  enum rtx_code rcode = GET_CODE (x);
+
+  /* Aka (vec_duplicate:RVVM1DI (reg/v:DI 143 [ x ]))  */
+  if (rcode == VEC_DUPLICATE && SCALAR_INT_MODE_P (GET_MODE (XEXP (x, 0
+cost_val += get_vector_costs ()->regmove->GR2VR;
+
+  *total = COSTS_N_INSNS (cost_val);
+
+  return true;
+}


I first read this wrong and thought we'd use GR2VR costs literally.  IMHO the 
costing makes sense like now.


The only thing I think we want for the patch (as Pan also raised last time) is 
the param to set those .vx costs to zero in order to ensure the tests test the 
right thing (--param=vx_preferred/gr2vr_cost or something).


According to patchwork the tests you add pass but shouldn't they actually fail 
with a GR2VR cost of 2?  I must be missing something.


--
Regards
Robin

Re: [pushed] c++: ill-formed constexpr function [PR113360]

[Jason Merrill]

On 4/17/25 10:06 AM, Patrick Palka wrote:

On Wed, 16 Apr 2025, Jason Merrill wrote:


If we already gave an error while parsing a function, we don't also need to
try to explain what's wrong with it when we later try to use it in a
constant-expression.  In the new testcase explain_invalid_constexpr_fn
couldn't find anything still in the function to complain about, so it said
because: followed by nothing.

We still try to constant-evaluate it to reduce error cascades, but we
shouldn't complain if it doesn't work very well.

This flag is similar to CLASSTYPE_ERRONEOUS that I added a while back.

@@ -33653,6 +33655,9 @@ cp_parser_function_definition_after_declarator 
(cp_parser* parser,
fn = finish_function (inline_p);
check_module_decl_linkage (fn);
  
+  if ((errorcount + sorrycount) > errs)

+DECL_STRUCT_FUNCTION (fn)->language->erroneous = true;
+


IIUC this means for

   template struct A { using type = T::type; };

   void f() {
 A a;
   }

   void g() {
 [] { A a; };
   }

we'll mark A, f, g and the lambda as erroneous,


Yes.


which doesn't seem
ideal (since e.g. A might still be "usable enough" despite its one
member being erroneous), but it's probably the best we can do without
making the mechanism a lot more complex.


How not ideal?  The flag doesn't prevent further compilation from using 
A, it just tries to silence further diagnostics and instantiations 
that are likely to also be erroneous.


Jason

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

[Jason Merrill]

On 4/21/25 6:46 AM, Nathaniel Shead wrote:

I don't really know how OpenMP works, hopefully this makes sense.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And for 15 (I guess after release)?


This is OK with a FIXME; presumably if we want to support running static 
constructors on the offload target we will eventually want to support 
that in modules as well.



In r15-2799-gf1bfba3a9b3f31, a new kind of global constructor was added.
Unfortunately this broke C++20 modules, as both the host and target
constructors were given the same mangled name.  This patch ensures that
only the host constructor gets the module name mangling for now.

PR c++/119864

gcc/cp/ChangeLog:

* decl2.cc (start_objects): Only use module initialized for
host.

gcc/testsuite/ChangeLog:

* g++.dg/modules/openmp-1.C: New test.

Signed-off-by: Nathaniel Shead 
---
  gcc/cp/decl2.cc | 4 +++-
  gcc/testsuite/g++.dg/modules/openmp-1.C | 9 +
  2 files changed, 12 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/modules/openmp-1.C

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 21156f1dd3b..5ce2fa76ce2 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -4184,7 +4184,9 @@ start_objects (bool initp, unsigned priority, bool 
has_body,
   bool omp_target = false)
  {
bool default_init = initp && priority == DEFAULT_INIT_PRIORITY;
-  bool is_module_init = default_init && module_global_init_needed ();
+  bool is_module_init = (default_init
+&& !omp_target
+&& module_global_init_needed ());
tree name = NULL_TREE;
  
if (is_module_init)

diff --git a/gcc/testsuite/g++.dg/modules/openmp-1.C 
b/gcc/testsuite/g++.dg/modules/openmp-1.C
new file mode 100644
index 000..b5a30ad8c91
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/openmp-1.C
@@ -0,0 +1,9 @@
+// PR c++/119864
+// { dg-do assemble }
+// { dg-additional-options "-fmodules -fopenmp" }
+// { dg-require-effective-target "fopenmp" }
+
+export module M;
+
+int foo();
+int x = foo();

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 10:47:31AM -0400, Jason Merrill wrote:
> On 4/21/25 6:46 AM, Nathaniel Shead wrote:
> > I don't really know how OpenMP works, hopefully this makes sense.
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > And for 15 (I guess after release)?
> 
> This is OK with a FIXME; presumably if we want to support running static
> constructors on the offload target we will eventually want to support that
> in modules as well.

The previous fixes were just to make sure omp_target mangles slightly
differently from !omp_target.  Though those names were non-exported names,
while supposedly the mangle_module_global_init returned names are global.

In the end the omp_target ctors should be nohost and !omp_target ctors
host, but using the same mangled name for both could cause problems if the
host needs to refer to the target copy somewhere.

> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/modules/openmp-1.C
> > @@ -0,0 +1,9 @@
> > +// PR c++/119864
> > +// { dg-do assemble }
> > +// { dg-additional-options "-fmodules -fopenmp" }
> > +// { dg-require-effective-target "fopenmp" }
> > +
> > +export module M;
> > +
> > +int foo();
> > +int x = foo();

I don't see why there should be omp_target case here though.
There is no #pragma omp declare target enter (x) or something similar.

Jakub

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

[Tobias Burnus]

Jason Merrill wrote:


This is OK with a FIXME; presumably if we want to support running 
static constructors on the offload target we will eventually want to 
support that in modules as well.


Well, the code that added support for static constructors
on the offload target exposed the issue. Thus, GCC already
supports this (but not in combination of modules).

The current patch is surely useful as it avoids issues
even when there is actually no constructor on the offload
side.

The question is why does this code trigger at all, given
that there is OpenMP but no offload code at all? And how
to fix it in case there is offload code and modules are used.

Tobias

PS The current testcases are for static constructors
on the offload side are:

* libgomp.c++/static-aggr-constructor-destructor-{1,2,3}.C

* g++.dg/gomp/pr119370.C

[PATCH] Document AArch64 changes for GCC 15

[Richard Sandiford]

The list is structured as:

- new configurations
- command-line changes
- ACLE changes
- everything else

As usual, the list of new architectures, CPUs, and features is from a
purely mechanical trawl of the associated .def files.  I've identified
features by their architectural name to try to improve searchability.
Similarly, the list of ACLE changes includes the associated ACLE
feature macros, again to try to improve searchability.

The list summarises some of the target-specific optimisations because
it sounded like Tamar had received feedback that people found such
information interesting.

I've used the passive tense for most entries, to try to follow the
style used elsewhere.

We don't yet define __ARM_FEATURE_FAMINMAX, but I'll fix that
separately.

How does this look?  Anything I missed?

I'll leave a few days for comments.

Thanks,
Richard

---
 htdocs/gcc-15/changes.html | 241 -
 1 file changed, 240 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index f03e29c8..dee476c7 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -681,7 +681,246 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
 
 New Targets and Target Specific Improvements
 
-
+AArch64
+
+
+  Support has been added for the AArch64 MinGW target
+(aarch64-w64-mingw32).  At present, this target only
+supports C, but further work is planned.
+  
+
+  The following architecture level is now supported by
+-march and related source-level constructs
+(GCC identifiers in parentheses):
+
+  Armv9.5-A (arm9.5-a)
+
+  
+  The following CPUs are now supported by -mcpu,
+-mtune, and related source-level constructs
+(GCC identifiers in parentheses):
+
+  Apple A12 (apple-a12)
+  Apple M1 (apple-m1)
+  Apple M2 (apple-m2)
+  Apple M3 (apple-m3)
+  Arm Cortex-A520AE (cortex-a520ae)
+  Arm Cortex-A720AE (cortex-a720ae)
+  Arm Cortex-A725 (cortex-a725)
+  Arm Cortex-R82AE (cortex-r82ae)
+  Arm Cortex-X925 (cortex-x925)
+  Arm Neoverse N3 (neoverse-n3)
+  Arm Neoverse V3 (neoverse-v3)
+  Arm Neoverse V3AE (neoverse-v3ae)
+  FUJITSU-MONAKA (fujitsu-monaka)
+  NVIDIA Grace (grace)
+  NVIDIA Olympus (olympus)
+  Qualcomm Oryon-1 (oryon-1)
+
+  
+  The following features are now supported by -march,
+-mcpu, and related source-level constructs
+(GCC modifiers in parentheses):
+
+  FEAT_CPA (+cpa), enabled by default for
+Arm9.5-A and above
+  
+  FEAT_FAMINMAX (+faminmax), enabled by default for
+Arm9.5-A and above
+  
+  FEAT_FCMA (+fcma), enabled by default for Armv8.3-A
+and above
+  
+  FEAT_FLAGM2 (+flagm2), enabled by default for
+Armv8.5-A and above
+  
+  FEAT_FP8 (+fp8)
+  FEAT_FP8DOT2 (+fp8dot2)
+  FEAT_FP8DOT4 (+fp8dot4)
+  FEAT_FP8FMA (+fp8fma)
+  FEAT_FRINTTS (+frintts), enabled by default for
+Armv8.5-A and above
+  
+  FEAT_JSCVT (+jscvt), enabled by default for
+Armv8.3-A and above
+  
+  FEAT_LUT (+lut), enabled by default for
+Arm9.5-A and above
+  
+  FEAT_LRCPC2 (+rcpc2), enabled by default for
+Armv8.4-A and above
+  
+  FEAT_SME_B16B16 (+sme-b16b16)
+  FEAT_SME_F16F16 (+sme-f16f16)
+  FEAT_SME2p1 (+sme2p1)
+  FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2)
+  FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4)
+  FEAT_SSVE_FP8FMA (+ssve-fp8fma)
+  FEAT_SVE_B16B16 (+sve-b16b16)
+  FEAT_SVE2p1 (+sve2p1), enabled by default for
+Armv9.4-A and above
+  
+  FEAT_WFXT (+wfxt), enabled by default for
+Armv8.7-A and above
+  
+  FEAT_XS (+xs), enabled by default for
+Armv8.7-A and above
+  
+
+The features listed as being enabled by default for Armv8.7-A or earlier
+were previously only selectable using the associated architecture level.
+For example, FEAT_FCMA was previously selected by
+-march=armv8.3-a and above (as it still is), but it wasn't
+previously selectable independently.
+  
+  The -mbranch-protection feature has been extended to
+support the Guarded Control Stack (GCS) extension.  This support
+is included in -mbranch-protection=standard and can
+be enabled individually using -mbranch-protection=gcs.
+  
+  The following additional changes have been made to the
+command-line options:
+
+  In order to align with other tools, the SME feature modifier
++sme no longer enables SVE.  However, GCC does not
+yet support using SME without SVE and instead rejects such
+combinations with a “not implemented” error.
+  
+  The options -mfix-cortex-a53-835769 and
+-mfix-cortex-a53-843419 are now silently ignored
+if the selected architecture is incompatible with Cortex-A53.
+This is particularly useful for toolchains that are configur

Re: [PATCH] Document AArch64 changes for GCC 15

[Kyrylo Tkachov]

> On 22 Apr 2025, at 15:31, Tamar Christina  wrote:
> 
>> -Original Message-
>> From: Richard Sandiford 
>> Sent: Tuesday, April 22, 2025 2:28 PM
>> To: Tamar Christina 
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
>> ktkac...@nvidia.com
>> Subject: Re: [PATCH] Document AArch64 changes for GCC 15
>> 
>> Tamar Christina  writes:
 -Original Message-
 From: Richard Sandiford 
 Sent: Tuesday, April 22, 2025 1:31 PM
 To: gcc-patches@gcc.gnu.org
 Cc: Richard Earnshaw ; ktkac...@nvidia.com;
 Tamar Christina 
 Subject: [PATCH] Document AArch64 changes for GCC 15
 
 The list is structured as:
 
 - new configurations
 - command-line changes
 - ACLE changes
 - everything else
 
 As usual, the list of new architectures, CPUs, and features is from a
 purely mechanical trawl of the associated .def files.  I've identified
 features by their architectural name to try to improve searchability.
 Similarly, the list of ACLE changes includes the associated ACLE
 feature macros, again to try to improve searchability.
 
 The list summarises some of the target-specific optimisations because
 it sounded like Tamar had received feedback that people found such
 information interesting.
 
 I've used the passive tense for most entries, to try to follow the
 style used elsewhere.
 
 We don't yet define __ARM_FEATURE_FAMINMAX, but I'll fix that
 separately.
 
 How does this look?  Anything I missed?
>>> 
>>> Thanks! Looks good! I think we're missing the ILP32 deprecation notice.
>>> But also crucially that the multilibs aren't build by default anymore.
>> 
>> I'd left ILP32 out since it's already mentioned in the Caveats section:
>> 
>>  In the AArch64 port, support for ILP32 (-mabi=ilp32) has
>>been deprecated and will be removed in a future release.
>>  
>> 
>> But I agree that the removal of the multilibs makes it worth a second
>> mention here.  (And also in case people interested in AArch64 don't
>> read the general Caveats section.)
>> 
>> How about:
>> 
>>  As noted above, support for ILP32 (-mabi=ilp32)
>>has been deprecated and will be removed in a future release.
>>aarch64*-elf targets no longer build the ILP32 multilibs.
>>  
>> 
> 
> Perfect!
> 
> Thanks for writing it up,

> Tamar
> 

Looks fine to me too, thanks for doing this.
We can incrementally adjust in the future if needed.
Kyrill


>> Thanks,
>> Richard

RE: [PATCH] Document AArch64 changes for GCC 15

[Tamar Christina]

> -Original Message-
> From: Richard Sandiford 
> Sent: Tuesday, April 22, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
> Tamar Christina 
> Subject: [PATCH] Document AArch64 changes for GCC 15
> 
> The list is structured as:
> 
> - new configurations
> - command-line changes
> - ACLE changes
> - everything else
> 
> As usual, the list of new architectures, CPUs, and features is from a
> purely mechanical trawl of the associated .def files.  I've identified
> features by their architectural name to try to improve searchability.
> Similarly, the list of ACLE changes includes the associated ACLE
> feature macros, again to try to improve searchability.
> 
> The list summarises some of the target-specific optimisations because
> it sounded like Tamar had received feedback that people found such
> information interesting.
> 
> I've used the passive tense for most entries, to try to follow the
> style used elsewhere.
> 
> We don't yet define __ARM_FEATURE_FAMINMAX, but I'll fix that
> separately.
> 
> How does this look?  Anything I missed?

Thanks! Looks good! I think we're missing the ILP32 deprecation notice.
But also crucially that the multilibs aren't build by default anymore.

The rest look OK to me

Thanks,
Tamar
> 
> I'll leave a few days for comments.
> 
> Thanks,
> Richard
> 
> ---
>  htdocs/gcc-15/changes.html | 241
> -
>  1 file changed, 240 insertions(+), 1 deletion(-)
> 
> diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
> index f03e29c8..dee476c7 100644
> --- a/htdocs/gcc-15/changes.html
> +++ b/htdocs/gcc-15/changes.html
> @@ -681,7 +681,246 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
>  
>  New Targets and Target Specific Improvements
> 
> -
> +AArch64
> +
> +
> +  Support has been added for the AArch64 MinGW target
> +(aarch64-w64-mingw32).  At present, this target only
> +supports C, but further work is planned.
> +  
> +
> +  The following architecture level is now supported by
> +-march and related source-level constructs
> +(GCC identifiers in parentheses):
> +
> +  Armv9.5-A (arm9.5-a)
> +
> +  
> +  The following CPUs are now supported by -mcpu,
> +-mtune, and related source-level constructs
> +(GCC identifiers in parentheses):
> +
> +  Apple A12 (apple-a12)
> +  Apple M1 (apple-m1)
> +  Apple M2 (apple-m2)
> +  Apple M3 (apple-m3)
> +  Arm Cortex-A520AE (cortex-a520ae)
> +  Arm Cortex-A720AE (cortex-a720ae)
> +  Arm Cortex-A725 (cortex-a725)
> +  Arm Cortex-R82AE (cortex-r82ae)
> +  Arm Cortex-X925 (cortex-x925)
> +  Arm Neoverse N3 (neoverse-n3)
> +  Arm Neoverse V3 (neoverse-v3)
> +  Arm Neoverse V3AE (neoverse-v3ae)
> +  FUJITSU-MONAKA (fujitsu-monaka)
> +  NVIDIA Grace (grace)
> +  NVIDIA Olympus (olympus)
> +  Qualcomm Oryon-1 (oryon-1)
> +
> +  
> +  The following features are now supported by -march,
> +-mcpu, and related source-level constructs
> +(GCC modifiers in parentheses):
> +
> +  FEAT_CPA (+cpa), enabled by default for
> +Arm9.5-A and above
> +  
> +  FEAT_FAMINMAX (+faminmax), enabled by default for
> +Arm9.5-A and above
> +  
> +  FEAT_FCMA (+fcma), enabled by default for Armv8.3-A
> +and above
> +  
> +  FEAT_FLAGM2 (+flagm2), enabled by default for
> +Armv8.5-A and above
> +  
> +  FEAT_FP8 (+fp8)
> +  FEAT_FP8DOT2 (+fp8dot2)
> +  FEAT_FP8DOT4 (+fp8dot4)
> +  FEAT_FP8FMA (+fp8fma)
> +  FEAT_FRINTTS (+frintts), enabled by default for
> +Armv8.5-A and above
> +  
> +  FEAT_JSCVT (+jscvt), enabled by default for
> +Armv8.3-A and above
> +  
> +  FEAT_LUT (+lut), enabled by default for
> +Arm9.5-A and above
> +  
> +  FEAT_LRCPC2 (+rcpc2), enabled by default for
> +Armv8.4-A and above
> +  
> +  FEAT_SME_B16B16 (+sme-b16b16)
> +  FEAT_SME_F16F16 (+sme-f16f16)
> +  FEAT_SME2p1 (+sme2p1)
> +  FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2)
> +  FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4)
> +  FEAT_SSVE_FP8FMA (+ssve-fp8fma)
> +  FEAT_SVE_B16B16 (+sve-b16b16)
> +  FEAT_SVE2p1 (+sve2p1), enabled by default for
> +Armv9.4-A and above
> +  
> +  FEAT_WFXT (+wfxt), enabled by default for
> +Armv8.7-A and above
> +  
> +  FEAT_XS (+xs), enabled by default for
> +Armv8.7-A and above
> +  
> +
> +The features listed as being enabled by default for Armv8.7-A or earlier
> +were previously only selectable using the associated architecture level.
> +For example, FEAT_FCMA was previously selected by
> +-march=armv8.3-a and above (as it still is), but it wasn't
> +previously selectable independently.
> +  
> +  The -mbranch-protection feature has been extended to
> +support the Guarded Control Stack (GCS) extension.  This support
> +i

Re: [PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

[Philipp Tomsich]

After reviewing the entire dependencies to get this enabled by
default, our current plan is as follows:
1. Send a v2 (there still were outstanding comments against some
testcases) of the "turn on by default for -O2" patch.
2. Address PR118873, PR119862, and PR119884 before merging the patch
that turns this on by default — we consider these three blockers.

While we just sent the v2 patch for enabling this by default (hoping
that we addressed all comments), PR118873 will keep us busy until the
end of the week, and PR119884 is likely to not drop until sometime
next week.
So optimistically, and assuming that there is sufficient reviewer
bandwidth, we could land the "enabled by default" on trunk towards the
end of next week.

Thanks,
Philipp.

On Sat, 19 Apr 2025 at 14:41, Jeff Law  wrote:
>
>
>
> On 4/18/25 4:37 PM, Sam James wrote:
> > Philipp Tomsich  writes:
> >
> >> Applied to trunk (16.0.0), thank you!
> >> Should this be backported to the GCC-15 release branch as well?
> >
> > BTW, what's the plan for enabling this on trunk now by default? (I don't 
> > recall if
> > some other issues were left.)
> There's already an approved patch to flip it on for gcc-16.
>
> jeff
>

Ping: [RFA, GCC 15] testsuite: XFAIL predcom-8.c on aarch64 [PR118407]

[Richard Sandiford]

Ping, since it sounds from irc like the release is coming soon :)

Richard Sandiford  writes:
> gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
> in the PR trail.  The fix didn't make it into GCC 15, so this patch
> XFAILs the test instead.
>
> Other targets might benefit from an XFAIL too, but people who work on
> those targets would be better placed to know the right conditions.
>
> Tested on aarch64-linux-gnu.  OK for GCC 15?
>
> FWIW, I was holding off on doing this in case the patch did make it in.
> With the patch applied, I get clean results locally on aarch64-linux-gnu
> for all testsuites except libphobos, where the some math routines are
> missing AArch64 support.
>
> Richard
>
>
> gcc/testsuite/
>   PR tree-optimization/118407
>   * gcc.dg/tree-ssa/predcom-8.c: Add XFAIL for aarch64.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
> index dcddf573145..22e4882c363 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
> @@ -10,4 +10,4 @@ int is_sorted(int *a, int n)
>  }
>  
>  /* { dg-final { scan-tree-dump "Executing predictive commoning without 
> unrolling" "pcom" } } */
> -/* { dg-final { scan-tree-dump-not "Invalid sum" "pcom" } } */
> +/* { dg-final { scan-tree-dump-not "Invalid sum" "pcom" { xfail aarch64*-*-* 
> } } } */

Re: [PATCH] asf: Enable pass at O2 or higher

[Konstantinos Eleftheriou]

We have sent a new version for this, with updated testcases
(https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681606.html).

Thanks,
Konstantinos

On Wed, Jan 29, 2025 at 8:32 PM Richard Sandiford
 wrote:
>
> Christoph Müllner  writes:
> > The avoid-store-forwarding pass is disabled by default and therefore
> > in the risk of bit-rotting.  This patch addresses this by enabling
> > the pass at O2 or higher.
> >
> > The assembly patterns in `bitfield-bitint-abi-align16.c` and
> > `bitfield-bitint-abi-align8.c` have been updated to account for
> > the ASF transformations.
> >
> > This was bootstrapped on x86-64 and AArch64 and showed no
> > regressions in the test suite (--enable-checking=yes,extra and
> > all languages).
> >
> > gcc/ChangeLog:
> >
> >   * doc/invoke.texi: Document asf as an O2 enabled option.
> >   * opts.cc: Enable asf at O2.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/aarch64/bitfield-bitint-abi-align16.c:
> >   Modify testcases to account for the asf transformations.
> >   * gcc.target/aarch64/bitfield-bitint-abi-align8.c: Likewise.
> >   * gcc.target/aarch64/avoid-store-forwarding-6.c: New test.
>
> Thanks for doing this.  Just a question about the testsuite updates:
>
> > diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
> > b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
> > index c29a230a771..b4501d81c45 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
> > @@ -91,10 +91,11 @@
> >  **   mov (w[0-9]+), 0
> >  **   bfi \3, w\2, 0, 1
> >  **   and x3, x\2, 9223372036854775807
> > -**   mov x2, 0
> > +**   mov (x[0-9]+), 0
> > +**   bfi \4, (x[0-9]+), 0, 8
> >  **   str xzr, \[sp\]
> >  **   strb\3, \[sp\]
> > -**   ldr x1, \[sp\]
> > +**   mov \5, 0
> >  **   add sp, sp, 16
> >  **   b   fp
> >  */
>
> This looks odd, in that \5 is used to match an output, whereas:
>
> > +**   bfi \4, (x[0-9]+), 0, 8
>
> allows any input.  I would have expected (x[0-9]+) to only be used for
> temporary results, with hard-coded registers being used for ABI-facing
> results.  Similarly, all uses were previously \n or hard-coded registers.
>
> Thanks,
> Richard
>
> > @@ -183,19 +184,21 @@
> >  **   sxtw(x[0-9]+), w1
> >  **   mov x0, \2
> >  **   and x7, \2, 9223372036854775807
> > +**   mov (x[0-9]+), 0
> >  **   mov (w[0-9]+), 0
> > -**   bfi \3, w\1, 0, 1
> > +**   bfi \4, w\1, 0, 1
> > +**   mov (x[0-9]+), \3
> > +**   bfi \5, (x[0-9]+), 0, 8
> > +**   stp x7, \5, \[sp\]
> >  **   strbwzr, \[sp, 16\]
> >  **   mov x6, x7
> >  **   mov x5, x7
> >  **   mov x4, x7
> > -**   mov x3, x7
> > -**   mov x2, x7
> > -**   str xzr, \[sp, 48\]
> > -**   strb\3, \[sp, 48\]
> > -**   ldr (x[0-9]+), \[sp, 48\]
> > -**   stp x7, \4, \[sp\]
> > -**   mov x1, x7
> > +**   mov \5, x7
> > +**   str \3, \[sp, 48\]
> > +**   strb\4, \[sp, 48\]
> > +**   mov \3, x7
> > +**   mov \6, x7
> >  **   bl  fp_stack
> >  **   sbfxx0, x0, 0, 63
> >  **...
> > @@ -343,10 +346,11 @@
> >  **   mov w0, w1
> >  **   mov (w[0-9]+), 0
> >  **   bfi \2, w\1, 0, 1
> > -**   mov x2, 0
> > +**   mov (x[0-9]+), 0
> > +**   bfi \3, (x[0-9]+), 0, 8
> >  **   str xzr, \[sp\]
> >  **   strb\2, \[sp\]
> > -**   ldr x1, \[sp\]
> > +**   mov \4, 0
> >  **...
> >  **   b   fp_stdarg
> >  */
> > diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c 
> > b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
> > index 13ffbf416ca..a9ac917d3a6 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
> > @@ -91,10 +91,11 @@
> >  **   mov (w[0-9]+), 0
> >  **   bfi \3, w\2, 0, 1
> >  **   and x3, x\2, 9223372036854775807
> > -**   mov x2, 0
> > +**   mov (x[0-9]+), 0
> > +**   bfi \4, (x[0-9]+), 0, 8
> >  **   str xzr, \[sp\]
> >  **   strb\3, \[sp\]
> > -**   ldr x1, \[sp\]
> > +**   mov \5, 0
> >  **   add sp, sp, 16
> >  **   b   fp
> >  */
> > @@ -183,19 +184,21 @@
> >  **   sxtw(x[0-9]+), w1
> >  **   mov x0, \2
> >  **   and x7, \2, 9223372036854775807
> > +**   mov (x[0-9]+), 0
> >  **   mov (w[0-9]+), 0
> > -**   bfi \3, w\1, 0, 1
> > +**   bfi \4, w\1, 0, 1
> > +**   mov (x[0-9]+), \3
> > +**   bfi \5, (x[0-9]+), 0, 8
> > +**   stp x7, \5, \[sp\]
> >  **   strbwzr, \[sp, 16\]
> >  **   mov x6, x7
> >  **   mov x5, x7
> >  **   mov x4, x7
> > -**   mov x3, x7
> > -**   mov x2, x7
> > -**   str xzr, \[sp, 48\]
> > -**   strb\3, \[sp, 48\]
> > -**   ldr (x[0-9]+), \[sp, 48\]
> > -**   stp x7, \4, \[sp\]
> > -**   mov 

[PATCH 2/2] libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]

[Tomasz Kamiński]

As P2286R8 and P2585R1 as now fully implemented, we now define
__cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
This macro is provided only in .

Uses of internal __glibcxx_format_ranges are also updated.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/version.def (format_ranges): Remove no_stdname and
update value.
* include/bits/version.h: Regenerate.
* src/c++23/std.cc.in: Replace __glibcxx_format_ranges with
__cpp_lib_format_ranges.
* testsuite/std/format/formatter/lwg3944.cc: Likewise.
* testsuite/std/format/parse_ctx.cc: Likewise.
* testsuite/std/format/string.cc: Likewise.
* testsuite/std/format/ranges/feature_test.cc: New test.
---
This is followup to be merged as separate commit with:
[PATCH v2] libstdc++: Implement formatters for queue, priority_queue and stack 
[PR109162]

OK for trunk and 15.2 with previous patch, once 15.1 will be released?

 libstdc++-v3/include/bits/version.def| 3 +--
 libstdc++-v3/include/bits/version.h  | 3 ++-
 libstdc++-v3/src/c++23/std.cc.in | 6 ++
 libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc   | 2 +-
 libstdc++-v3/testsuite/std/format/parse_ctx.cc   | 2 +-
 libstdc++-v3/testsuite/std/format/ranges/feature_test.cc | 9 +
 libstdc++-v3/testsuite/std/format/string.cc  | 2 +-
 7 files changed, 17 insertions(+), 10 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/feature_test.cc

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 0afaf0dec24..737b3f421bf 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1416,9 +1416,8 @@ ftms = {
   // 202207 P2286R8 Formatting Ranges
   // 202207 P2585R1 Improving default container formatting
   // LWG3750 Too many papers bump __cpp_lib_format
-  no_stdname = true; // TODO remove
   values = {
-v = 1; // TODO 202207
+v = 202207;
 cxxmin = 23;
 hosted = yes;
   };
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index 980fee641e9..59ff0cee043 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1562,8 +1562,9 @@
 
 #if !defined(__cpp_lib_format_ranges)
 # if (__cplusplus >= 202100L) && _GLIBCXX_HOSTED
-#  define __glibcxx_format_ranges 1L
+#  define __glibcxx_format_ranges 202207L
 #  if defined(__glibcxx_want_all) || defined(__glibcxx_want_format_ranges)
+#   define __cpp_lib_format_ranges 202207L
 #  endif
 # endif
 #endif /* !defined(__cpp_lib_format_ranges) && 
defined(__glibcxx_want_format_ranges) */
diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstdc++-v3/src/c++23/std.cc.in
index 5e18ad73908..6da6d382914 100644
--- a/libstdc++-v3/src/c++23/std.cc.in
+++ b/libstdc++-v3/src/c++23/std.cc.in
@@ -1315,8 +1315,7 @@ export namespace std
   using std::format_to_n;
   using std::format_to_n_result;
   using std::formatted_size;
-// FIXME __cpp_lib_format_ranges
-#if __cplusplus > 202002L
+#if __cpp_lib_format_ranges
   using std::formattable;
 #endif
   using std::formatter;
@@ -1332,8 +1331,7 @@ export namespace std
   using std::wformat_context;
   using std::wformat_parse_context;
   using std::wformat_string;
-// FIXME __cpp_lib_format_ranges
-#ifdef __glibcxx_format_ranges
+#ifdef __cpp_lib_format_ranges
   using std::format_kind;
   using std::range_format;
   using std::range_formatter;
diff --git a/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc 
b/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
index 1f3edc9cb03..07e63af5652 100644
--- a/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
+++ b/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
@@ -18,7 +18,7 @@ void test_lwg3944()
   std::format(L"{}", "hello"); // { dg-error "here" }
   std::format(L"{}", std::string_view("hello")); // { dg-error "here" }
   std::format(L"{}", std::string("hello")); // { dg-error "here" }
-#ifdef __glibcxx_format_ranges
+#ifdef __cpp_lib_format_ranges
   // LWG 3944 does not change this, it's still valid.
   std::format(L"{}", std::vector{'h', 'e', 'l', 'l', 'o'});
 #endif
diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc 
b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
index b338ac7b762..b5dd7cdba78 100644
--- a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
+++ b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
@@ -108,7 +108,7 @@ is_std_format_spec_for(std::string_view spec)
   }
 }
 
-#if __glibcxx_format_ranges
+#if __cpp_lib_format_ranges
 constexpr bool escaped_strings_supported = true;
 #else
 constexpr bool escaped_strings_supported = false;
diff --git a/libstdc++-v3/testsuite/std/format/ranges/feature_test.cc 
b/libstdc++-v3/testsuite/std/format/ranges/feature_test.cc
new file mode 100644
index 000..80d2cea80ca
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/format

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

[Tobias Burnus]

Jason Merrill wrote:

On 4/22/25 11:04 AM, Tobias Burnus wrote:

The question is why does this code trigger at all, given
that there is OpenMP but no offload code at all? And how
to fix it in case there is offload code and modules are used.


This seems to be because of:


  if (module_global_init_needed ())
    {
  // Make sure there's a default priority entry.   if 
(!static_init_fini_fns[true])

    static_init_fini_fns[true] = priority_map_t::create_ggc ();
  if (static_init_fini_fns[true]->get_or_insert 
(DEFAULT_INIT_PRIORITY))

    has_module_inits = true;

  if (flag_openmp)
    {
  if (!static_init_fini_fns[2 + true])
    static_init_fini_fns[2 + true] = 
priority_map_t::create_ggc ();
  static_init_fini_fns[2 + true]->get_or_insert 
(DEFAULT_INIT_PRIORITY);

    }
    }


Here we're forcing a target module init function as well as host. If 
we remove the flag_openmp block, Nathaniel's patch is unnecessary (but 
may still be desirable).


I currently do not see whether the code is needed in this case or not, 
but I assume it is, if we want to support static initializers?!?


In any case, it seems as if the condition 'if (flag_openmp)' 
additionally requires '&& lookup_attribute ("omp declare target", 
DECL_ATTRIBUTES (decl))'.


Tobias

PS: Sorry, I badly need to finish a couple of other things, first – and 
I am already way behind (related to any of several GCC topics, filing 
one OpenMP_VV bug, to GSoC and to something hobby related – but first 
victualing before the shop closes).

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

[Jakub Jelinek]

On Tue, Apr 22, 2025 at 07:21:14PM +0200, Tobias Burnus wrote:
> I currently do not see whether the code is needed in this case or not, but I
> assume it is, if we want to support static initializers?!?
> 
> In any case, it seems as if the condition 'if (flag_openmp)' additionally
> requires '&& lookup_attribute ("omp declare target", DECL_ATTRIBUTES
> (decl))'.

Depends on when exactly it is done, there is the implicit declare target
discovery during gimplification, e.g. the var itself might not be initially
omp declare target but have its address used in some omp declare target
static var initializer or pragma omp declare target could appear as the last
one in the TU.
If it is always done after the whole TU was parsed and went through this
implicit declare target discovery, then I agree we could use
lookup_attribute, otherwise we can't.

Jakub

Re: Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 'targetm.arm_eabi_unwinder' [PR118794] (was: [Linaro-TCWG-CI] gcc-15-9463-gaa3e72f9430: 2 regressions on arm)

[Christophe Lyon]

Hi!

On Tue, 22 Apr 2025 at 13:55, Thomas Schwinge  wrote:
>
> Hi!
>
> On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression 
>  wrote:
> > Our automatic CI has detected problems related to your patch(es). Please 
> > find some details below.
> >
> > In bootstrap_check master-arm-check_bootstrap, after:
> >   | commit gcc-15-9463-gaa3e72f9430
> >   | Author: Thomas Schwinge 
> >   | Date:   Thu Mar 27 23:06:37 2025 +0100
> >   |
> >   | Add test cases for exception handling constructs in dead code for 
> > GCN, nvptx target and OpenMP 'target' offloading [PR118794]
> >   |
> >   | PR target/118794
> >   | gcc/testsuite/
> >   | * g++.target/gcn/exceptions-pr118794-1.C: New.
> >   | ... 7 lines of the commit log omitted.
> >
> > Produces 2 regressions:
> >   |
> >   | regressions.sum:
> >   | Running libgomp:libgomp.c++/c++.exp ...
> >   | FAIL: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times 
> > optimized "gimple_call <__builtin_eh_pointer, " 1
> >   | FAIL: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times 
> > optimized "gimple_call <__builtin_unwind_resume, " 1
>
> Ah, sorry for that.  This is due to 'targetm.arm_eabi_unwinder', as per:
>
> gcc/config/arm/arm.cc:#define TARGET_ARM_EABI_UNWINDER true
> gcc/config/c6x/c6x.cc:#define TARGET_ARM_EABI_UNWINDER true
>
> ..., which for ARM is conditional to '#if ARM_UNWIND_INFO' (defined in
> 'gcc/config/arm/bpabi.h', used for various GCC configurations), and for
> C6x unconditional.
>
> This gets us:
>
> --- target-exceptions-pr118794-1.C.269t.optimized
> +++ target-exceptions-pr118794-1.C.270t.optimized
> [...]
>  __attribute__((omp declare target))
>  void f ()
> [...]
>gimple_call <__dt_comp , NULL, &c>
> -  gimple_call <__builtin_eh_pointer, _7, 2>
> -  gimple_call <__builtin_unwind_resume, NULL, _7>
> +  gimple_call <__builtin_cxa_end_cleanup, NULL>
>
>  }
> [...]
>
> There doesn't appear to be an effective-target keyword for
> 'targetm.arm_eabi_unwinder' specifically, do we need to add one?
> Or, other test cases appear to use effective-target 'arm_eabi' to
> disambiguate the two variants; is that the right thing to use here, too?
> (..., plus 'tic6x-*-*' in this case?)  OK to push the attached
> "Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 
> 'targetm.arm_eabi_unwinder' [PR118794]"?
> (Could Arm/C6x maintainers please test this for me?)
>
I confirm that on arm-linux-gnueabihf, with your patch:
PASS: libgomp.c++/target-exceptions-pr118794-1.C (test for excess errors)
PASS: libgomp.c++/target-exceptions-pr118794-1.C execution test
PASS: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times
optimized "gimple_call <__builtin_cxa_end_cleanup, " 1
and the two FAILs have disappeared.

Thanks,

Christophe

>
> Grüße
>  Thomas
>
>
> > Used configuration :
> >  *CI config* tcwg_bootstrap_check master-arm-check_bootstrap
> >  *configure and test flags:* none, autodetected on 
> > armv8l-unknown-linux-gnueabihf
> >
> > We track this bug report under 
> > https://linaro.atlassian.net/browse/GNU-1562. Please let us know if you 
> > have a fix.
> >
> > If you have any questions regarding this report, please ask on 
> > linaro-toolch...@lists.linaro.org mailing list.
> >
> > -8<--8<--8<--
> >
> > The information below contains the details of the failures, and the ways to 
> > reproduce a debug environment:
> >
> > You can find the failure logs in *.log.1.xz files in
> >  * 
> > https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts/00-sumfiles/
> > The full lists of regressions and improvements as well as configure and 
> > make commands are in
> >  * 
> > https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts/notify/
> > The list of [ignored] baseline and flaky failures are in
> >  * 
> > https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts/sumfiles/xfails.xfail
> >
> > Current build   : 
> > https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1236/artifact/artifacts
> > Reference build : 
> > https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-build/1235/artifact/artifacts
> >
> > Instruction to reproduce the build : 
> > https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/aa3e72f943032e5f074b2bd2fd06d130dda8760b/tcwg_bootstrap_check/master-arm-check_bootstrap/reproduction_instructions.txt
> >
> > Full commit : 
> > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=aa3e72f943032e5f074b2bd2fd06d130dda8760b
>
>

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

[Jerry D]

Ping! Can we backport this to 15 please?

Regards,

Jerry

On 4/18/25 6:35 PM, Jerry D wrote:

On 4/18/25 5:48 PM, Jerry D wrote:

I will be committing a fix for this to the 16 mainline tonight.

I am requesting Release Manager approval to push to 15 release branch 
after full testing here.


Regards,

Jerry

See attached diff.

2025-04-18  Steven G. Kargl  

PR fortran/119836
* resolve.cc(check_pure_function, pure_subroutine): Fix checking for
an impure subprogram within a DO CONCURRENT construct.


2025-04-18  Steven G. Kargl  

PR fortran/119836
* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: Ditto.
* gfortran.dg/pr119836_3.f90: Ditto.
* gfortran.dg/pr119836_4.f90: Ditto.


I have committed to 16 and the backport to 15 is ready to go pending RM 
approval.


Best Regards,

Jerry

commit 5927077029d61fdd32531530b9568cf6949fe0dd (HEAD -> gcc15)
Author: Steven G. Kargl 
Date:   Fri Apr 18 18:05:10 2025 -0700

     Fortran: Fix checking for IMPURE in DO CONCURRENT.

     PR fortran/119836

     gcc/fortran/ChangeLog:

     * resolve.cc (check_pure_function): Fix checking for
     an impure subprogram within a DO CONCURRENT construct.
     (pure_subroutine): Ditto.

     gcc/testsuite/ChangeLog:

     * gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
     dg-error test.
     * gfortran.dg/pr119836_1.f90: New test.
     * gfortran.dg/pr119836_2.f90: New test.
     * gfortran.dg/pr119836_3.f90: New test.
     * gfortran.dg/pr119836_4.f90: New test.

     (cherry picked from commit f9ea46d946887a05d7ecbca5aeeb99fd868f6e70)

[Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

[Andre Vehreschild]

Hi all,

attached patch fixes an illegal use of gfc_current_locus during the
check()-phase of several coarray functions. Instead gfc_current_intrinsic_where
needs to be used. This error does not crash gfortran reliably. But valgrind
reports an access to uninitialized memory. I therefore do not know how to test
this in the testsuite.

Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
From 56a5099b9ed307b1c3cd1bfbe2058ef74f43 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Tue, 22 Apr 2025 10:11:52 +0200
Subject: [PATCH] Fortran: Use correct location in check of coarray functions
 [PR119200]

Use gfc_current_intrinsic_where during check(), because
gfc_current_locus is not set to correct location or at all.

	PR fortran/119200

gcc/fortran/ChangeLog:

	* check.cc (gfc_check_lcobound): Use locus from intrinsic_where.
	(gfc_check_image_index): Same.
	(gfc_check_num_images): Same.
	(gfc_check_team_number): Same.
	(gfc_check_this_image): Same.
	(gfc_check_ucobound): Same.
---
 gcc/fortran/check.cc | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 356e0d7f678..91945bea1e3 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -3835,7 +3835,8 @@ gfc_check_lcobound (gfc_expr *coarray, gfc_expr *dim, gfc_expr *kind)
 {
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
-  gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
+  gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+		   gfc_current_intrinsic_where);
   return false;
 }
 
@@ -6572,7 +6573,8 @@ gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub,
 
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
-  gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
+  gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+		   gfc_current_intrinsic_where);
   return false;
 }
 
@@ -6622,7 +6624,8 @@ gfc_check_num_images (gfc_expr *team_or_team_number)
 {
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
-  gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
+  gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+		   gfc_current_intrinsic_where);
   return false;
 }
 
@@ -6651,7 +6654,8 @@ gfc_check_team_number (gfc_expr *team)
 {
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
-  gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
+  gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+		   gfc_current_intrinsic_where);
   return false;
 }
 
@@ -6668,7 +6672,8 @@ gfc_check_this_image (gfc_actual_arglist *args)
 
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
-  gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
+  gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+		   gfc_current_intrinsic_where);
   return false;
 }
 
@@ -6967,7 +6972,8 @@ gfc_check_ucobound (gfc_expr *coarray, gfc_expr *dim, gfc_expr *kind)
 {
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
-  gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
+  gfc_fatal_error ("Coarrays disabled at L, use %<-fcoarray=%> to enable",
+		   gfc_current_intrinsic_where);
   return false;
 }
 
-- 
2.49.0

Re: [PHASE1 PATCH] Use optimize free lists for alloc_pages

[Andi Kleen]

On Tue, Apr 22, 2025 at 01:27:34PM +0200, Richard Biener wrote:
> I assume this passed bootstrap & regtest?

Yes it did

> 
> This is OK for trunk after we've released GCC 15.1.

Thanks. 

Andi

Re: [PATCH] Document AArch64 changes for GCC 15

[Richard Sandiford]

Tamar Christina  writes:
>> -Original Message-
>> From: Richard Sandiford 
>> Sent: Tuesday, April 22, 2025 1:31 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
>> Tamar Christina 
>> Subject: [PATCH] Document AArch64 changes for GCC 15
>> 
>> The list is structured as:
>> 
>> - new configurations
>> - command-line changes
>> - ACLE changes
>> - everything else
>> 
>> As usual, the list of new architectures, CPUs, and features is from a
>> purely mechanical trawl of the associated .def files.  I've identified
>> features by their architectural name to try to improve searchability.
>> Similarly, the list of ACLE changes includes the associated ACLE
>> feature macros, again to try to improve searchability.
>> 
>> The list summarises some of the target-specific optimisations because
>> it sounded like Tamar had received feedback that people found such
>> information interesting.
>> 
>> I've used the passive tense for most entries, to try to follow the
>> style used elsewhere.
>> 
>> We don't yet define __ARM_FEATURE_FAMINMAX, but I'll fix that
>> separately.
>> 
>> How does this look?  Anything I missed?
>
> Thanks! Looks good! I think we're missing the ILP32 deprecation notice.
> But also crucially that the multilibs aren't build by default anymore.

I'd left ILP32 out since it's already mentioned in the Caveats section:

  In the AArch64 port, support for ILP32 (-mabi=ilp32) has
been deprecated and will be removed in a future release.
  

But I agree that the removal of the multilibs makes it worth a second
mention here.  (And also in case people interested in AArch64 don't
read the general Caveats section.)

How about:

  As noted above, support for ILP32 (-mabi=ilp32)
has been deprecated and will be removed in a future release.
aarch64*-elf targets no longer build the ILP32 multilibs.
  

Thanks,
Richard

RE: [PATCH] Document AArch64 changes for GCC 15

[Tamar Christina]

> -Original Message-
> From: Richard Sandiford 
> Sent: Tuesday, April 22, 2025 2:28 PM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
> ktkac...@nvidia.com
> Subject: Re: [PATCH] Document AArch64 changes for GCC 15
> 
> Tamar Christina  writes:
> >> -Original Message-
> >> From: Richard Sandiford 
> >> Sent: Tuesday, April 22, 2025 1:31 PM
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
> >> Tamar Christina 
> >> Subject: [PATCH] Document AArch64 changes for GCC 15
> >>
> >> The list is structured as:
> >>
> >> - new configurations
> >> - command-line changes
> >> - ACLE changes
> >> - everything else
> >>
> >> As usual, the list of new architectures, CPUs, and features is from a
> >> purely mechanical trawl of the associated .def files.  I've identified
> >> features by their architectural name to try to improve searchability.
> >> Similarly, the list of ACLE changes includes the associated ACLE
> >> feature macros, again to try to improve searchability.
> >>
> >> The list summarises some of the target-specific optimisations because
> >> it sounded like Tamar had received feedback that people found such
> >> information interesting.
> >>
> >> I've used the passive tense for most entries, to try to follow the
> >> style used elsewhere.
> >>
> >> We don't yet define __ARM_FEATURE_FAMINMAX, but I'll fix that
> >> separately.
> >>
> >> How does this look?  Anything I missed?
> >
> > Thanks! Looks good! I think we're missing the ILP32 deprecation notice.
> > But also crucially that the multilibs aren't build by default anymore.
> 
> I'd left ILP32 out since it's already mentioned in the Caveats section:
> 
>   In the AArch64 port, support for ILP32 (-mabi=ilp32) has
> been deprecated and will be removed in a future release.
>   
> 
> But I agree that the removal of the multilibs makes it worth a second
> mention here.  (And also in case people interested in AArch64 don't
> read the general Caveats section.)
> 
> How about:
> 
>   As noted above, support for ILP32 (-mabi=ilp32)
> has been deprecated and will be removed in a future release.
> aarch64*-elf targets no longer build the ILP32 multilibs.
>   
> 

Perfect!

Thanks for writing it up,
Tamar

> Thanks,
> Richard

[RFA, GCC 15] aarch64: Define __ARM_FEATURE_FAMINMAX

[Richard Sandiford]

We implemented FAMINMAX ACLE support but failed to define the
associated feature macro.

Tested on aarch64-linux-gnu & pushed to trunk.  OK for GCC 15 too?

Sorry for the late patch.  I only noticed this macro was missing while
writing up the GCC 15 changes.  It would be good to get it in for
15.1 since the proposed changes.html entry specifically refers to it.

Richard


gcc/
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_FAMINMAX.

gcc/testsuite/
* gcc.target/aarch64/pragma_cpp_predefs_4.c: Test
__ARM_FEATURE_FAMINMAX.
---
 gcc/config/aarch64/aarch64-c.cc   |  1 +
 .../gcc.target/aarch64/pragma_cpp_predefs_4.c | 15 +++
 2 files changed, 16 insertions(+)

diff --git a/gcc/config/aarch64/aarch64-c.cc b/gcc/config/aarch64/aarch64-c.cc
index d1e2ab9831d..98337b7f693 100644
--- a/gcc/config/aarch64/aarch64-c.cc
+++ b/gcc/config/aarch64/aarch64-c.cc
@@ -293,6 +293,7 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
   aarch64_def_or_undef (TARGET_SME2, "__ARM_FEATURE_SME2", pfile);
   aarch64_def_or_undef (AARCH64_HAVE_ISA (SME2p1),
"__ARM_FEATURE_SME2p1", pfile);
+  aarch64_def_or_undef (TARGET_FAMINMAX, "__ARM_FEATURE_FAMINMAX", pfile);
 
   /* Not for ACLE, but required to keep "float.h" correct if we switch
  target between implementations that do or do not support ARMv8.2-A
diff --git a/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_4.c 
b/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_4.c
index dcac6d5eb65..3799fb46df1 100644
--- a/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_4.c
+++ b/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_4.c
@@ -315,3 +315,18 @@
 #ifndef __ARM_FEATURE_FP8DOT2
 #error Foo
 #endif
+
+#pragma GCC target "arch=armv9.4-a"
+#ifdef __ARM_FEATURE_FAMINMAX
+#error Foo
+#endif
+
+#pragma GCC target "arch=armv9.5-a"
+#ifndef __ARM_FEATURE_FAMINMAX
+#error Foo
+#endif
+
+#pragma GCC target "arch=armv8-a+faminmax"
+#ifndef __ARM_FEATURE_FAMINMAX
+#error Foo
+#endif
-- 
2.43.0

[PATCH v2] asf: Enable pass at O2 or higher

[Konstantinos Eleftheriou]

The avoid-store-forwarding pass is disabled by default and therefore
in the risk of bit-rotting.  This patch addresses this by enabling
the pass at O2 or higher.

The assembly patterns in `bitfield-bitint-abi-align16.c` and
`bitfield-bitint-abi-align8.c` have been updated to account for
the asf transformations.

Co-Authored-By: Christoph Müllner 

gcc/ChangeLog:

* doc/invoke.texi: Document asf as an O2 enabled option.
* opts.cc: Enable asf at O2.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-bitint-abi-align16.c:
Modify testcases to account for the asf transformations.
* gcc.target/aarch64/bitfield-bitint-abi-align8.c: Likewise.
* gcc.target/aarch64/avoid-store-forwarding-6.c: New test.
---
 gcc/doc/invoke.texi   |  3 +-
 gcc/opts.cc   |  1 +
 .../aarch64/avoid-store-forwarding-6.c| 29 +++
 .../aarch64/bitfield-bitint-abi-align16.c | 22 --
 .../aarch64/bitfield-bitint-abi-align8.c  | 22 --
 5 files changed, 58 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/avoid-store-forwarding-6.c

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 020442aa032e..918e76307dcd 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12790,6 +12790,7 @@ also turns on the following optimization flags:
 @c Please keep the following list alphabetized!
 @gccoptlist{-falign-functions  -falign-jumps
 -falign-labels  -falign-loops
+-favoid-store-forwarding
 -fcaller-saves
 -fcode-hoisting
 -fcrossjumping
@@ -12957,7 +12958,7 @@ Many CPUs will stall for many cycles when a load 
partially depends on previous
 smaller stores.  This pass tries to detect such cases and avoid the penalty by
 changing the order of the load and store and then fixing up the loaded value.
 
-Disabled by default.
+Enabled by default at @option{-O2} and higher.
 
 @opindex ffp-contract
 @item -ffp-contract=@var{style}
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 5e7b77dab2fd..c29008aa365c 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -627,6 +627,7 @@ static const struct default_options default_options_table[] 
=
 { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_ftree_sra, NULL, 1 },
 
 /* -O2 and -Os optimizations.  */
+{ OPT_LEVELS_2_PLUS, OPT_favoid_store_forwarding, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fcaller_saves, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fcode_hoisting, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fcrossjumping, NULL, 1 },
diff --git a/gcc/testsuite/gcc.target/aarch64/avoid-store-forwarding-6.c 
b/gcc/testsuite/gcc.target/aarch64/avoid-store-forwarding-6.c
new file mode 100644
index ..320fa5e101e6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/avoid-store-forwarding-6.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Same as avoid-store-forwarding-1.c but without -favoid-store-forwarding.  */
+
+typedef union {
+char arr_8[8];
+long long_value;
+} DataUnion;
+
+long ssll_1 (DataUnion *data, char x)
+{
+  data->arr_8[0] = x;
+  return data->long_value;
+}
+
+long ssll_2 (DataUnion *data, char x)
+{
+  data->arr_8[1] = x;
+  return data->long_value;
+}
+
+long ssll_3 (DataUnion *data, char x)
+{
+  data->arr_8[7] = x;
+  return data->long_value;
+}
+
+/* { dg-final { scan-assembler-times {ldr\tx[0-9]+, 
\[x[0-9]+\]\n\tstrb\tw[0-9]+, \[x[0-9]+(, \d+)?\]\n\tbfi\tx[0-9]+, x[0-9]+, 
\d+, \d+} 3 } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
index c29a230a7713..11dc86bcfd7d 100644
--- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
@@ -91,10 +91,11 @@
 ** mov (w[0-9]+), 0
 ** bfi \3, w\2, 0, 1
 ** and x3, x\2, 9223372036854775807
-** mov x2, 0
+** mov x1, 0
+** bfi x1, x2, 0, 8
 ** str xzr, \[sp\]
 ** strb\3, \[sp\]
-** ldr x1, \[sp\]
+** mov x2, 0
 ** add sp, sp, 16
 ** b   fp
 */
@@ -183,19 +184,21 @@
 ** sxtw(x[0-9]+), w1
 ** mov x0, \2
 ** and x7, \2, 9223372036854775807
+** mov x3, 0
 ** mov (w[0-9]+), 0
 ** bfi \3, w\1, 0, 1
+** mov x1, x3
+** bfi x1, x2, 0, 8
+** stp x7, x1, \[sp\]
 ** strbwzr, \[sp, 16\]
 ** mov x6, x7
 ** mov x5, x7
 ** mov x4, x7
+** mov x1, x7
+** str x3, \[sp, 48\]
+** strb\3, \[sp, 48\]
 ** mov x3, x7
 ** mov x2, x7
-** str xzr, \[sp, 48\]
-** strb\3, \[sp, 48\]
-** ldr (x[0-9]+), \[sp, 48\]
-** stp x7, \4, \[sp\]
-** mov x1, x7
 ** bl  fp_stack
 ** sbfxx0, x0, 0, 63
 **...
@@ -343,10 +346,11 @@
 ** mov w0, w1
 ** mov (w[0-9]+), 0
 ** bfi \2, w

Re: [PATCH] sanitizer: Store no_sanitize attribute value in uint32 instead of unsigned

[Kees Cook]

On April 22, 2025 12:08:51 AM PDT, Sam James  wrote:
>Kees Cook  writes:
>
>> On Thu, Apr 10, 2025 at 05:17:51PM -0700, Keith Packard wrote:
>>> A target using 16-bit ints won't have enough bits to hold the whole
>>> flag_sanitize set. Be explicit about using uint32 for the attribute data.
>>> 
>>> Signed-off-by: Keith Packard 
>>> ---
>>>  gcc/c-family/c-attribs.cc | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
>>> index 5a0e3d328ba..2a4ae10838a 100644
>>> --- a/gcc/c-family/c-attribs.cc
>>> +++ b/gcc/c-family/c-attribs.cc
>>> @@ -1420,12 +1420,12 @@ add_no_sanitize_value (tree node, unsigned int 
>>> flags)
>>>if (flags == old_value)
>>> return;
>>>  
>>> -  TREE_VALUE (attr) = build_int_cst (unsigned_type_node, flags);
>>> +  TREE_VALUE (attr) = build_int_cst (uint32_type_node, flags);
>>>  }
>>>else
>>>  DECL_ATTRIBUTES (node)
>>>= tree_cons (get_identifier ("no_sanitize"),
>>> -  build_int_cst (unsigned_type_node, flags),
>>> +  build_int_cst (uint32_type_node, flags),
>>>DECL_ATTRIBUTES (node));
>>>  }
>>
>> This looks correct to me. Martin, is this something you (or someone
>> else) can get committed for GCC 15?
>
>Martin isn't involved with GCC development anymore. But it's not clear

Ah! Okay, it seemed like he had some relatively recent commits.

>to me why this is critical for GCC 15. (Any further patches for 15.1
>need to be both approved and then approved by release managers).

It's not critical. I was thinking it would be nice to have in 15 as it was a 
small/easy change.

>Did you need this for something on the Linux side?

No, this is not needed for Linux. I have been following Keith's use of the 
sanitizers on the picolibc project[1] and thought I might be able to help find 
someone that could commit this fix.

>More likely that if approved, it could then go into 15.2 which will be
>in a few months (not a year unlike > X.3).

Any release is fine. My suggestion for 15 was just based on seeing it as a 
trivial fix and not sufficiently understanding the GCC release process. :)

Thanks for looking at it!

-Kees

[1] https://keithp.com/blogs/sanitizer-fun/

-- 
Kees Cook

[PATCH] [14] Use --param=aarch64-autovec-preference=2 instead of =sve-only

[Richard Biener]

This updates the backported test.

Pushed.

PR tree-optimization/119706
* g++.target/aarch64/sve/pr119706.C: Adjust --param
aarch64-autovec-preference.
---
 gcc/testsuite/g++.target/aarch64/sve/pr119706.C | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/g++.target/aarch64/sve/pr119706.C 
b/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
index 40fefe5f4fb..b185c12496f 100644
--- a/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
+++ b/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O3 -mcpu=neoverse-v2 
--param=aarch64-autovec-preference=sve-only -w" } */
+/* { dg-options "-O3 -mcpu=neoverse-v2 --param=aarch64-autovec-preference=2 
-w" } */
 
 namespace a {
 typedef long unsigned b;
@@ -175,4 +175,4 @@ void u::v(cd, b) {
   df.r();
 }
 } // namespace basic
-} // namespace a
\ No newline at end of file
+} // namespace a
-- 
2.43.0

Re: Ping: [RFA, GCC 15] testsuite: XFAIL predcom-8.c on aarch64 [PR118407]

[Richard Biener]

On Tue, 22 Apr 2025, Richard Sandiford wrote:

> Ping, since it sounds from irc like the release is coming soon :)

Fine with me.

> Richard Sandiford  writes:
> > gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
> > in the PR trail.  The fix didn't make it into GCC 15, so this patch
> > XFAILs the test instead.
> >
> > Other targets might benefit from an XFAIL too, but people who work on
> > those targets would be better placed to know the right conditions.
> >
> > Tested on aarch64-linux-gnu.  OK for GCC 15?
> >
> > FWIW, I was holding off on doing this in case the patch did make it in.
> > With the patch applied, I get clean results locally on aarch64-linux-gnu
> > for all testsuites except libphobos, where the some math routines are
> > missing AArch64 support.
> >
> > Richard
> >
> >
> > gcc/testsuite/
> > PR tree-optimization/118407
> > * gcc.dg/tree-ssa/predcom-8.c: Add XFAIL for aarch64.
> > ---
> >  gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c 
> > b/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
> > index dcddf573145..22e4882c363 100644
> > --- a/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
> > @@ -10,4 +10,4 @@ int is_sorted(int *a, int n)
> >  }
> >  
> >  /* { dg-final { scan-tree-dump "Executing predictive commoning without 
> > unrolling" "pcom" } } */
> > -/* { dg-final { scan-tree-dump-not "Invalid sum" "pcom" } } */
> > +/* { dg-final { scan-tree-dump-not "Invalid sum" "pcom" { xfail 
> > aarch64*-*-* } } } */
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

[PATCH] aarch64: Update FP8 dependencies for -mcpu=olympus

[Kyrylo Tkachov]

Hi all,

We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the
FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for
-mcpu=olympus to support all of them.
Fix the definition to include the relevant sub-features explicitly.

Bootstrapped and tested on aarch64-none-linux-gnu.

I’m pushing this to trunk, is it also ok for the GCC 15 branch? I’d like to 
have the right CPU features enabled for the realease.
Thanks,
Kyrill 


Signed-off-by: Kyrylo Tkachov 

gcc/

* config/aarch64/aarch64-cores.def (olympus): Add fp8fma, fp8dot4
explicitly.



0001-aarch64-Update-FP8-dependencies-for-mcpu-olympus.patch
Description: 0001-aarch64-Update-FP8-dependencies-for-mcpu-olympus.patch

Re: [PATCH] aarch64: Update FP8 dependencies for -mcpu=olympus

[Richard Biener]

On Tue, Apr 22, 2025 at 3:54 PM Kyrylo Tkachov  wrote:
>
> Hi all,
>
> We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the
> FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for
> -mcpu=olympus to support all of them.
> Fix the definition to include the relevant sub-features explicitly.
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
> I’m pushing this to trunk, is it also ok for the GCC 15 branch? I’d like to 
> have the right CPU features enabled for the realease.

OK, it's your risk to getting it more wrong than before ;)

> Thanks,
> Kyrill
>
>
> Signed-off-by: Kyrylo Tkachov 
>
> gcc/
>
> * config/aarch64/aarch64-cores.def (olympus): Add fp8fma, fp8dot4
> explicitly.
>

Re: [PATCH] asf: Enable pass at O2 or higher

[Andi Kleen]

On Wed, Jan 29, 2025 at 10:33:14AM +0100, Christoph Müllner wrote:
> The avoid-store-forwarding pass is disabled by default and therefore
> in the risk of bit-rotting.  This patch addresses this by enabling
> the pass at O2 or higher.
> 
> The assembly patterns in `bitfield-bitint-abi-align16.c` and
> `bitfield-bitint-abi-align8.c` have been updated to account for
> the ASF transformations.
> 
> This was bootstrapped on x86-64 and AArch64 and showed no
> regressions in the test suite (--enable-checking=yes,extra and
> all languages).

I dont think this is a good idea without some target specific cost
model. On x86 it will almost certainly generate extra unnecessary
instructions for cases where the cpu can already do fast forwarding.

Basically you would need to teach it about tables like the ones in
https://chipsandcheese.com/p/a-peek-at-sapphire-rapids
(search for load/store)

I suppose it would be ok to enable for some targets that dont have
the necessary hardware but i dont think that would be any modern
x86 part or likely more generally any modern high performance CPU.

Andi

[PATCH 0/3] A fix fixes for match and fold_stmt

[Andrew Pinski]

I noticed while improving forwprop, that fold_stmt sometimes would return true
even if there was no change that happened. These fixes 3 of those places.
In the first one we had:
```
tmp = a ? b : c
if (tmp != 0)
```

And match and simplify would return the same thing but that was just because of 
the order of patterns in match.pd.

The second one is that we would return true when simplifying:
```
if (0 != 0)
```
and
```
if (1 != 0)
```

as we would do constant folding on the comparison and then change it back to. 
This has an early out so
that we don't even waste time going through constant folding.

The 3rd and final one of this branch is related to the first one where we had:
```
if (bool != 0)
```
and the comparison would simplify back to `bool` which then gets placed back 
into the GIMPLE_COND as `bool != 0`.
So we need to reject it while placing it back into the GIMPLE_COND if the 
variable didn't change.

There is a 4th patch which I am working on dealing with trapping math and 
comparisons. I am trying to figure out the
best way of implementing it.


Thanks,
Andrew Pinski

Andrew Pinski (3):
  match: Move `(cmp (cond @0 @1 @2) @3)` simplification after the bool
compare simplifcation
  gimple-fold: Return early for GIMPLE_COND with true/false
  gimple-fold: Don't replace `bool_var != 0` with `bool_var` inside
GIMPLE_COND

 gcc/gimple-fold.cc | 25 -
 gcc/match.pd   | 31 +--
 2 files changed, 37 insertions(+), 19 deletions(-)

-- 
2.43.0

[PATCH 1/3] match: Move `(cmp (cond @0 @1 @2) @3)` simplification after the bool compare simplifcation

[Andrew Pinski]

This moves the `(cmp (cond @0 @1 @2) @3)` simplifcation to be after the boolean 
comparison
simplifcations so that we don't end up simplifing into the same thing for a 
GIMPLE_COND.

gcc/ChangeLog:

* match.pd: Move `(cmp (cond @0 @1 @2) @3)` simplifcation after
the bool comparison simplifications.

Signed-off-by: Andrew Pinski 
---
 gcc/match.pd | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/gcc/match.pd b/gcc/match.pd
index ba036e52837..0fe90a6edc4 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7759,20 +7759,6 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (cmp (bit_and@2 @0 integer_pow2p@1) @1)
   (icmp @2 { build_zero_cst (TREE_TYPE (@0)); })))
 
-#if GIMPLE
-/* From fold_binary_op_with_conditional_arg handle the case of
-   rewriting (a ? b : c) > d to a ? (b > d) : (c > d) when the
-   compares simplify.  */
-(for cmp (simple_comparison)
- (simplify
-  (cmp:c (cond @0 @1 @2) @3)
-  /* Do not move possibly trapping operations into the conditional as this
- pessimizes code and causes gimplification issues when applied late.  */
-  (if (!FLOAT_TYPE_P (TREE_TYPE (@3))
-   || !operation_could_trap_p (cmp, true, false, @3))
-   (cond @0 (cmp! @1 @3) (cmp! @2 @3)
-#endif
-
 (for cmp (ge lt)
 /* x < 0 ? ~y : y into (x >> (prec-1)) ^ y. */
 /* x >= 0 ? ~y : y into ~((x >> (prec-1)) ^ y). */
@@ -8119,6 +8105,23 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
replace if (x == 0) with tem = ~x; if (tem != 0) which is
clearly less optimal and which we'll transform again in forwprop.  */
 
+#if GIMPLE
+/* From fold_binary_op_with_conditional_arg handle the case of
+   rewriting (a ? b : c) > d to a ? (b > d) : (c > d) when the
+   compares simplify.
+   This should be after the boolean comparison simplification so
+   that it can remove the outer comparison before appling it to
+   the inner condtional operands.  */
+(for cmp (simple_comparison)
+ (simplify
+  (cmp:c (cond @0 @1 @2) @3)
+  /* Do not move possibly trapping operations into the conditional as this
+ pessimizes code and causes gimplification issues when applied late.  */
+  (if (!FLOAT_TYPE_P (TREE_TYPE (@3))
+   || !operation_could_trap_p (cmp, true, false, @3))
+   (cond @0 (cmp! @1 @3) (cmp! @2 @3)
+#endif
+
 /* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
where ~Y + 1 == pow2 and Z = ~Y.  */
 (for cst (VECTOR_CST INTEGER_CST)
-- 
2.43.0

[PATCH 2/3] gimple-fold: Return early for GIMPLE_COND with true/false

[Andrew Pinski]

To speed up things slightly so not needing to call all the way through
to match and simplify, we should return early for true/false on GIMPLE_COND.

gcc/ChangeLog:

* gimple-fold.cc (fold_stmt_1): For GIMPLE_COND return early
for true/false.

Signed-off-by: Andrew Pinski 
---
 gcc/gimple-fold.cc | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 94d5a1ebbd7..2381a82d2b1 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -6646,12 +6646,19 @@ fold_stmt_1 (gimple_stmt_iterator *gsi, bool inplace, 
tree (*valueize) (tree),
   break;
 case GIMPLE_COND:
   {
+   gcond *gc = as_a  (stmt);
+   /* If the cond is already true/false, just return false.  */
+   if (gimple_cond_true_p (gc)
+   || gimple_cond_false_p (gc))
+ {
+   fold_undefer_overflow_warnings (false, stmt, 0);
+   return false;
+ }
/* Canonicalize operand order.  */
-   tree lhs = gimple_cond_lhs (stmt);
-   tree rhs = gimple_cond_rhs (stmt);
+   tree lhs = gimple_cond_lhs (gc);
+   tree rhs = gimple_cond_rhs (gc);
if (tree_swap_operands_p (lhs, rhs))
  {
-   gcond *gc = as_a  (stmt);
gimple_cond_set_lhs (gc, rhs);
gimple_cond_set_rhs (gc, lhs);
gimple_cond_set_code (gc,
-- 
2.43.0

[PATCH 3/3] gimple-fold: Don't replace `bool_var != 0` with `bool_var` inside GIMPLE_COND

[Andrew Pinski]

Since match and simplify will simplify `bool_var != 0` to just `bool_var` and
this is inside a GIMPLE_COND, fold_stmt will return true but nothing has 
changed.
So let's just reject the replacement if we are replacing with the same 
simplification
inside replace_stmt_with_simplification. This can speed up things slightly 
because
now fold_stmt won't return true on all GIMPLE_COND with `bool_var != 0` in it.

gcc/ChangeLog:

* gimple-fold.cc (replace_stmt_with_simplification): Return false
if replacing `bool_var != 0` with `bool_var` in GIMPLE_COND.

Signed-off-by: Andrew Pinski 
---
 gcc/gimple-fold.cc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 2381a82d2b1..de1f1a44aa3 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -6246,8 +6246,16 @@ replace_stmt_with_simplification (gimple_stmt_iterator 
*gsi,
  false, NULL_TREE)))
gimple_cond_set_condition (cond_stmt, code, ops[0], ops[1]);
   else if (code == SSA_NAME)
-   gimple_cond_set_condition (cond_stmt, NE_EXPR, ops[0],
-  build_zero_cst (TREE_TYPE (ops[0])));
+   {
+ /* If setting the gimple cond to the same thing,
+return false as nothing changed.  */
+ if (gimple_cond_code (cond_stmt) == NE_EXPR
+ && operand_equal_p (gimple_cond_lhs (cond_stmt), ops[0])
+ && integer_zerop (gimple_cond_rhs (cond_stmt)))
+   return false;
+ gimple_cond_set_condition (cond_stmt, NE_EXPR, ops[0],
+build_zero_cst (TREE_TYPE (ops[0])));
+   }
   else if (code == INTEGER_CST)
{
  if (integer_zerop (ops[0]))
-- 
2.43.0

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

[Jakub Jelinek]

On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote:
> I will be committing a fix for this to the 16 mainline tonight.
> 
> I am requesting Release Manager approval to push to 15 release branch after
> full testing here.
> 
> Regards,
> 
> Jerry
> 
> See attached diff.
> 
> 2025-04-18  Steven G. Kargl  
> 
> PR fortran/119836
> * resolve.cc(check_pure_function, pure_subroutine): Fix checking for
> an impure subprogram within a DO CONCURRENT construct.
> 
> 
> 2025-04-18  Steven G. Kargl  
> 
> PR fortran/119836
> * gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
> dg-error test.
> * gfortran.dg/pr119836_1.f90: New test.
> * gfortran.dg/pr119836_2.f90: Ditto.
> * gfortran.dg/pr119836_3.f90: Ditto.
> * gfortran.dg/pr119836_4.f90: Ditto.

Ok for 15.1 if you can commit this before RC2 is being made.

Jakub

Re: [PATCH 2/2] libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]

[Jonathan Wakely]

On Tue, 22 Apr 2025 at 13:53, Tomasz Kamiński  wrote:
>
> As P2286R8 and P2585R1 as now fully implemented, we now define
> __cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
> This macro is provided only in .
>
> Uses of internal __glibcxx_format_ranges are also updated.
>
> PR libstdc++/109162
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (format_ranges): Remove no_stdname and
> update value.
> * include/bits/version.h: Regenerate.
> * src/c++23/std.cc.in: Replace __glibcxx_format_ranges with
> __cpp_lib_format_ranges.
> * testsuite/std/format/formatter/lwg3944.cc: Likewise.
> * testsuite/std/format/parse_ctx.cc: Likewise.
> * testsuite/std/format/string.cc: Likewise.
> * testsuite/std/format/ranges/feature_test.cc: New test.
> ---
> This is followup to be merged as separate commit with:
> [PATCH v2] libstdc++: Implement formatters for queue, priority_queue and 
> stack [PR109162]
>
> OK for trunk and 15.2 with previous patch, once 15.1 will be released?

Yes, thanks.

>
>  libstdc++-v3/include/bits/version.def| 3 +--
>  libstdc++-v3/include/bits/version.h  | 3 ++-
>  libstdc++-v3/src/c++23/std.cc.in | 6 ++
>  libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc   | 2 +-
>  libstdc++-v3/testsuite/std/format/parse_ctx.cc   | 2 +-
>  libstdc++-v3/testsuite/std/format/ranges/feature_test.cc | 9 +
>  libstdc++-v3/testsuite/std/format/string.cc  | 2 +-
>  7 files changed, 17 insertions(+), 10 deletions(-)
>  create mode 100644 libstdc++-v3/testsuite/std/format/ranges/feature_test.cc
>
> diff --git a/libstdc++-v3/include/bits/version.def 
> b/libstdc++-v3/include/bits/version.def
> index 0afaf0dec24..737b3f421bf 100644
> --- a/libstdc++-v3/include/bits/version.def
> +++ b/libstdc++-v3/include/bits/version.def
> @@ -1416,9 +1416,8 @@ ftms = {
>// 202207 P2286R8 Formatting Ranges
>// 202207 P2585R1 Improving default container formatting
>// LWG3750 Too many papers bump __cpp_lib_format
> -  no_stdname = true; // TODO remove
>values = {
> -v = 1; // TODO 202207
> +v = 202207;
>  cxxmin = 23;
>  hosted = yes;
>};
> diff --git a/libstdc++-v3/include/bits/version.h 
> b/libstdc++-v3/include/bits/version.h
> index 980fee641e9..59ff0cee043 100644
> --- a/libstdc++-v3/include/bits/version.h
> +++ b/libstdc++-v3/include/bits/version.h
> @@ -1562,8 +1562,9 @@
>
>  #if !defined(__cpp_lib_format_ranges)
>  # if (__cplusplus >= 202100L) && _GLIBCXX_HOSTED
> -#  define __glibcxx_format_ranges 1L
> +#  define __glibcxx_format_ranges 202207L
>  #  if defined(__glibcxx_want_all) || defined(__glibcxx_want_format_ranges)
> +#   define __cpp_lib_format_ranges 202207L
>  #  endif
>  # endif
>  #endif /* !defined(__cpp_lib_format_ranges) && 
> defined(__glibcxx_want_format_ranges) */
> diff --git a/libstdc++-v3/src/c++23/std.cc.in 
> b/libstdc++-v3/src/c++23/std.cc.in
> index 5e18ad73908..6da6d382914 100644
> --- a/libstdc++-v3/src/c++23/std.cc.in
> +++ b/libstdc++-v3/src/c++23/std.cc.in
> @@ -1315,8 +1315,7 @@ export namespace std
>using std::format_to_n;
>using std::format_to_n_result;
>using std::formatted_size;
> -// FIXME __cpp_lib_format_ranges
> -#if __cplusplus > 202002L
> +#if __cpp_lib_format_ranges
>using std::formattable;
>  #endif
>using std::formatter;
> @@ -1332,8 +1331,7 @@ export namespace std
>using std::wformat_context;
>using std::wformat_parse_context;
>using std::wformat_string;
> -// FIXME __cpp_lib_format_ranges
> -#ifdef __glibcxx_format_ranges
> +#ifdef __cpp_lib_format_ranges
>using std::format_kind;
>using std::range_format;
>using std::range_formatter;
> diff --git a/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc 
> b/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
> index 1f3edc9cb03..07e63af5652 100644
> --- a/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
> +++ b/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
> @@ -18,7 +18,7 @@ void test_lwg3944()
>std::format(L"{}", "hello"); // { dg-error "here" }
>std::format(L"{}", std::string_view("hello")); // { dg-error "here" }
>std::format(L"{}", std::string("hello")); // { dg-error "here" }
> -#ifdef __glibcxx_format_ranges
> +#ifdef __cpp_lib_format_ranges
>// LWG 3944 does not change this, it's still valid.
>std::format(L"{}", std::vector{'h', 'e', 'l', 'l', 'o'});
>  #endif
> diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc 
> b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> index b338ac7b762..b5dd7cdba78 100644
> --- a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> +++ b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> @@ -108,7 +108,7 @@ is_std_format_spec_for(std::string_view spec)
>}
>  }
>
> -#if __glibcxx_format_ranges
> +#if __cpp_lib_format_ranges
>  constexpr bool escaped_strings_supported 

Re: [PATCH] libphobos: enable for sparc64-unknown-linux-gnu

[Iain Buclaw]

Excerpts from Sam James's message of April 20, 2025 2:46 am:
> This bootstraps with some test failures but works well enough to build
> 11..15.
> 
> libphobos/ChangeLog:
> 
>   * configure.tgt: Add sparc64-unknown-linux-gnu as a supported target.
> ---
> As discussed on IRC. OK? I'd like to backport it to branches in due course
> once they're all open and some time on trunk too, as it would make life
> easier for us in bootstrapping from 11.
> 

Fine with me, I trusted you've tested everything.

Thanks,
Iain.

Re: [GCC16,RFC,V2 03/14] aarch64: add new insn definition for st2g

[Indu Bhagat]

On 4/15/25 9:21 AM, Richard Sandiford wrote:

Indu Bhagat  writes:

Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
instruction. It stores an allocation tag to two tag granules of memory.

TBD:
   - Not too sure what is the best way to generate the st2g yet; A
 subsequent patch will emit them in one of the target hooks.


Regarding the previous thread about this:

 https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668671.html



Apologies for this one again slipping through the cracks.


and your question about whether all types of store tag instructions
should be volatile: if we went for that approach, then yeah, I think so.

As I mentioned there, I don't think we should use (unspec ...) memory
addresses.

But thinking more about it: can we guarantee that GCC will only use
these instruction patterns with base registers that are aligned to
16 bytes?  If so, then perhaps an alternative would be to model
them as read-modify-write operations to the whole granule (even though
the actual instructions leave normal memory untouched and only change
the tags).  That is, rather than:



I think so. Each stack var is assigned a granule of its own (16-bytes); 
for alloca, we align explicitly; and each pointer is based off the SP 
(which is also 16-byte aligned for AAPCS64).  IIRC, FEAT_MTE*  are 
available in AArch64 only.


BTW, the aarch64.md file has this comment for stg:
";; STG doesn't align the address but aborts with alignment fault
;; when the address is not 16-byte aligned."

Just curious: the same should be true for all MTE load/store tag 
instructions, isnt it ?  I cant seem to find the above specific 
information in the ARM MTE instruction specification  "Arm Architecture 
Reference Manual for A-profile architecture."...




gcc/ChangeLog:

* config/aarch64/aarch64.md (st2g): New definition.
---
  gcc/config/aarch64/aarch64.md | 20 
  1 file changed, 20 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 0c7aebb838cd..d3223e275c51 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -8475,6 +8475,26 @@
[(set_attr "type" "memtag")]
  )
  
+;; ST2G updates allocation tags for two memory granules (i.e. 32 bytes) at

+;; once, without zero initialization.
+(define_insn "st2g"
+  [(set (mem:QI (unspec:DI
+[(plus:DI (match_operand:DI 1 "register_operand" "rk")
+  (match_operand:DI 2 "aarch64_granule16_simm9" "i"))]
+UNSPEC_TAG_SPACE))
+   (and:QI (lshiftrt:DI (match_operand:DI 0 "register_operand" "rk")
+(const_int 56)) (const_int 15)))
+   (set (mem:QI (unspec:DI
+[(plus:DI (match_dup 1)
+  (match_operand:DI 3 "aarch64_granule16_simm9" "i"))]
+UNSPEC_TAG_SPACE))
+   (and:QI (lshiftrt:DI (match_dup 0)
+(const_int 56)) (const_int 15)))]
+  "TARGET_MEMTAG && (INTVAL (operands[2]) - 16 == INTVAL (operands[3]))"
+  "st2g\\t%0, [%1, #%2]"
+  [(set_attr "type" "memtag")]
+)
+


...this, we could do:

(set (match_operand:OI 0 "aarch64_granule_memory_operand" "+")
  (unspec_volatile:OI
[(match_dup 0)
 (match_operand:DI 1 "register_operand" "rk")]
UNSPECV...))

Using OImode (256 bytes) indicates that two full granules are affected
by the store, but that no other memory is affected.  The (match_dup 0)
read indicates that this store does not kill any previous store to the
same 256 bytes (since the contents of normal memory don't change).
The unspec_volatile should ensure that nothing tries to remove the
store as dead (which would especially be a problem when clearing tags).

Using a single memory operand for the whole instruction has the advantage
of only requiring one offset to be represented, rather than having both
operands 2 and 3 in the original pattern.  It also copes more easily
with cases where the offset is zero for the first or second address,
since no (plus ...) should be present in that case.

Thanks,
Richard

Re: [GCC16,RFC,V2 02/14] aarch64: add new define_insn for subg

[Indu Bhagat]

On 4/15/25 8:35 AM, Richard Sandiford wrote:

Hi,

Indu Bhagat  writes:

subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE)
instruction.  It can be used to subtract an immediate value scaled by
the tag granule from the address in the source register.

gcc/ChangeLog:

* config/aarch64/aarch64.md (subg): New definition.


In my previous comment about this patch:

   https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668669.html

I hadn't realised that the pattern follows the existing "addg" pattern.
But...



And I just realized that it seems some of my edits to this commit got 
lost in a rebase or such in my work branch.


I had addressed the review comments earlier on this patch, but they 
didnt make it out in RFC V2.



---
  gcc/config/aarch64/aarch64.md | 17 +
  1 file changed, 17 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 031e621c98a1..0c7aebb838cd 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -8416,6 +8416,23 @@
[(set_attr "type" "memtag")]
  )
  
+(define_insn "subg"

+  [(set (match_operand:DI 0 "register_operand" "=rk")
+   (ior:DI
+(and:DI (minus:DI (match_operand:DI 1 "register_operand" "rk")
+ (match_operand:DI 2 "aarch64_granule16_uimm6" "i"))
+(const_int -1080863910568919041)) ;; 0xf0ff...
+(ashift:DI
+ (unspec:QI
+  [(and:QI (lshiftrt:DI (match_dup 1) (const_int 56)) (const_int 15))
+   (match_operand:QI 3 "aarch64_memtag_tag_offset" "i")]
+  UNSPEC_GEN_TAG)
+ (const_int 56]
+  "TARGET_MEMTAG"
+  "subg\\t%0, %1, #%2, #%3"
+  [(set_attr "type" "memtag")]
+)
+
  (define_insn "subp"
[(set (match_operand:DI 0 "register_operand" "=r")
(minus:DI


...subtractions of constants are canonically expressed using (plus ...)
of a negative number, rather than (minus ...) of a positive number.
So I think we should instead add subg to the existing addg pattern.
That is, in:

(define_insn "addg"
   [(set (match_operand:DI 0 "register_operand" "=rk")
(ior:DI
 (and:DI (plus:DI (match_operand:DI 1 "register_operand" "rk")
  (match_operand:DI 2 "aarch64_granule16_uimm6" "i"))
 (const_int -1080863910568919041)) ;; 0xf0ff...
 (ashift:DI
  (unspec:QI
   [(and:QI (lshiftrt:DI (match_dup 1) (const_int 56)) (const_int 15))
(match_operand:QI 3 "aarch64_memtag_tag_offset" "i")]
   UNSPEC_GEN_TAG)
  (const_int 56]
   "TARGET_MEMTAG"
   "addg\\t%0, %1, #%2, #%3"
   [(set_attr "type" "memtag")]
)

the aarch64_granule16_uimm6 would be replaced with a predicate that
accepts all multiples of 16 in the range [-1008, 1008].  Then the
output pattern would generate an addg or subg instruction based on
whether operand 2 is negative.



;; These constants are used as a const_int in MTE instructions
(define_constants
  [; 0xf0ff...
   ; Tag mask for the 4-bit tag stored in the top 8 bits of a pointer.
   (MEMTAG_TAG_MASK -1080863910568919041)])

Above was requested by Andrew.  If what is shown here (both defining the 
constant and using it below) in the email OK to you, I can submit a 
separate patch to then use this const in existing irg, ldg..


with predicates.md saying:

(define_predicate "aarch64_granule16_imm6"
  (and (match_code "const_int")
   (match_test "IN_RANGE (INTVAL (op), -1008, 1008)
&& !(INTVAL (op) & 0xf)")))

addg pattern as follows:

(define_insn "addg"
  [(set (match_operand:DI 0 "register_operand")
(ior:DI
 (and:DI (plus:DI (match_operand:DI 1 "register_operand")
  (match_operand:DI 2 "aarch64_granule16_imm6"))
 (const_int MEMTAG_TAG_MASK))
 (ashift:DI
   (unspec:DI [(match_dup 1)
   (match_operand:QI 3 "aarch64_memtag_tag_offset")]
   UNSPEC_GEN_TAG)
  (const_int 56]
  "TARGET_MEMTAG"
  {@ [ cons: =0 , 1  , 2 , 3 ; attrs: type ]
 [ rk   , rk , I , I ; memtag   ] addg\t%0, %1, #%2, #%3
 [ rk   , rk , J , I ; memtag   ] subg\t%0, %1, #%2, #%3
  }
)

I.e, now using the mode of unspec:DI instead of the earlier unspec:QI. 
It also addresses the following comment from previous review cycle:





+  [(and:QI (lshiftrt:DI (match_dup 1) (const_int 56)) (const_int 15))
+   (match_operand:QI 3 "aarch64_memtag_tag_offset" "i")]
+  UNSPEC_GEN_TAG)


Similarly here for the and vs. lshiftrt.  But since it's an unspec
anyway, we could just use:

(unspec:DI [(match_dup 1)
(match_operand:QI 3 "aarch64_memtag_tag_offset")]
   UNSPEC_GEN_TAG)

Re: [PATCH] libstdc++: fix possible undefined atomic lock-free type aliases in module std

[Jonathan Wakely]

On Sun, 20 Apr 2025 at 10:03, ZENG Hao wrote:
>
> When building for 'i386-*' targets, all basic types are 'sometimes lock-free'
> and thus std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are
> not declared. In the header , they are placed in preprocessor
> condition __cpp_lib_atomic_lock_free_type_aliases. In module std, they should
> be the same.

Thanks for the patch. I'll push this to trunk, but I don't think it's
urgent for GCC 15.1 so I will do the backport for the 15.2 release.


>
> libstdc++-v3/ChangeLog:
>
> * src/c++23/std.cc.in: Add preprocessor condition
> __cpp_lib_atomic_lock_free_type_aliases for
> std::atomic_signed_lock_free and std::atomic_unsigned_lock_free.
> ---
>  libstdc++-v3/src/c++23/std.cc.in | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libstdc++-v3/src/c++23/std.cc.in 
> b/libstdc++-v3/src/c++23/std.cc.in
> index 5e18ad73908..ea50496b057 100644
> --- a/libstdc++-v3/src/c++23/std.cc.in
> +++ b/libstdc++-v3/src/c++23/std.cc.in
> @@ -599,7 +599,9 @@ export namespace std
>using std::atomic_schar;
>using std::atomic_short;
>using std::atomic_signal_fence;
> +#ifdef __cpp_lib_atomic_lock_free_type_aliases
>using std::atomic_signed_lock_free;
> +#endif
>using std::atomic_size_t;
>using std::atomic_store;
>using std::atomic_store_explicit;
> @@ -622,7 +624,9 @@ export namespace std
>using std::atomic_uintptr_t;
>using std::atomic_ullong;
>using std::atomic_ulong;
> +#ifdef __cpp_lib_atomic_lock_free_type_aliases
>using std::atomic_unsigned_lock_free;
> +#endif
>using std::atomic_ushort;
>using std::atomic_wait;
>using std::atomic_wait_explicit;
> --
> 2.49.0
>

Re: [GCC16,RFC,V2 04/14] aarch64: add new definition for post-index st2g

[Indu Bhagat]

On 4/15/25 11:52 AM, Richard Sandiford wrote:

Indu Bhagat  writes:

Using post-index st2g is a faster way of memory tagging/untagging.
Because a post-index 'st2g tag, [addr], #32' is equivalent to:
stg tag, addr, #0
stg tag, addr, #16
add addr, addr, #32

TBD:
   - Currently generated by in the aarch64 backend.  Not sure if this is
 the right way to do it.


If we do go for the "aarch64_granule_memory_operand" approach that
I described for patch 3, then that predicate (and the associated constrant)
could handle PRE_MODIFY and POST_MODIFY addresseses, which would remove
the need for separate patterns.



I think I understand :)  I will try it out.  I guess one of the unknowns 
for me is whether the PRE_MODIFY / POST_MODIFY will be generated as 
expected, even when the involved instructions have an unspec...



   - Also not clear how to weave in the generation of stz2g.


I think stz2g could be:

(set (match_operand:OI 0 "aarch64_granule_memory_operand" "+")
  (unspec_volatile:OI
[(const_int 0)
 (match_operand:DI 1 "register_operand" "rk")]
UNSPECV...))



The question I have is what changes will be necessary to have the 
compiler DTRT:


  i.e. for the zero-init case, instead of
stg x1, [x1, #0]
str wzr, [x1]
  generate
stzg x0, [x0]

  Similarly for the value init case, instead of
stg x0, [x0, #0]
mov w1, 42
str w1, [x0]
   generate
mov  w1, #42
stgp x1, xzr, [x0]

I guess once I have worked out the patterns for above, I should see the 
combiner in action DTRT, but I dont know for sure if something else in 
the compiler will also need adjustments for these new MTE insns.



I think in practice stz2g will need a separate pattern from st2g,
rather than being an alternatives of the same pattern.  (That's because
the suggested pattern for st2g uses a (match_dup 0), which isn't subject
to constraint matching.)

Thanks,
Richard



ChangeLog:
* gcc/config/aarch64/aarch64.md

---
[New in RFC V2]
---
  gcc/config/aarch64/aarch64.md | 20 
  1 file changed, 20 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index d3223e275c51..175aed3146ac 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -8495,6 +8495,26 @@
[(set_attr "type" "memtag")]
  )
  
+;; ST2G with post-index writeback.

+(define_insn "*st2g_post"
+  [(set (mem:QI (unspec:DI
+[(plus:DI (match_operand:DI 1 "register_operand" "=&rk")
+  (const_int 0))]
+UNSPEC_TAG_SPACE))
+   (and:QI (lshiftrt:DI (match_operand:DI 0 "register_operand" "rk")
+(const_int 56)) (const_int 15)))
+   (set (mem:QI (unspec:DI
+[(plus:DI (match_dup 1) (const_int -16))]
+UNSPEC_TAG_SPACE))
+   (and:QI (lshiftrt:DI (match_dup 0)
+(const_int 56)) (const_int 15)))
+(set (match_dup 1)
+ (plus:DI (match_dup 1) (match_operand:DI 2 "aarch64_granule16_simm9" 
"i")))]
+  "TARGET_MEMTAG"
+  "st2g\\t%0, [%1], #%2"
+  [(set_attr "type" "memtag")]
+)
+
  ;; Load/Store 64-bit (LS64) instructions.
  (define_insn "ld64b"
[(set (match_operand:V8DI 0 "register_operand" "=r")

[PATCH] testsuite: AMDGCN test for vect-early-break_38.c as well to consistent architecture [PR119286]

[Tamar Christina]

Hi All,

I had missed this one during the AMDGCN test failures.

Like vect-early-break_18.c this test is also scalaring the
loads and thus leading to unexpected vectorization for this
testcase.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Cross checked the failing case on amdgcn-amdhsa
and all pass now.

Ok for master? and GCC 15?

Thanks,
Tamar

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-early-break_38.c: Force -march=gfx908 for amdgcn.

---
diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c 
b/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c
index 
36fc6a6eb60fae70f8f05a3d9435f5adce025847..010e7ea7e327f4bb0e33560e24dd3e6c5462d659
 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c
@@ -2,6 +2,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_early_break } */
 /* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-march=gfx908" { target amdgcn*-*-* } } */
 
 #ifndef N
 #define N 803


-- 
diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c b/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c
index 36fc6a6eb60fae70f8f05a3d9435f5adce025847..010e7ea7e327f4bb0e33560e24dd3e6c5462d659 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_38.c
@@ -2,6 +2,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_early_break } */
 /* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-march=gfx908" { target amdgcn*-*-* } } */
 
 #ifndef N
 #define N 803

[PATCH] GCN: Properly switch sections in 'gcn_hsa_declare_function_name' [PR119737]

[Thomas Schwinge]

From: Andrew Pinski 

There are GCN/C++ target as well as offloading codes, where the hard-coded
section names in 'gcn_hsa_declare_function_name' do not fit, and assembly thus
fails:

LLVM ERROR: Size expression must be absolute.

This commit progresses GCN target:

[-FAIL: g++.dg/init/call1.C  -std=gnu++17 (internal compiler error: Aborted 
signal terminated program as)-]
[-FAIL:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++17 (test for excess 
errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++17 [-compilation 
failed to produce executable-]{+execution test+}
[-FAIL: g++.dg/init/call1.C  -std=gnu++26 (internal compiler error: Aborted 
signal terminated program as)-]
[-FAIL:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++26 (test for excess 
errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++26 [-compilation 
failed to produce executable-]{+execution test+}
UNSUPPORTED: g++.dg/init/call1.C  -std=gnu++98: exception handling not 
supported

..., and GCN offloading:

[-XFAIL: libgomp.c++/target-exceptions-throw-1.C (internal compiler error: 
Aborted signal terminated program as)-]
[-XFAIL: libgomp.c++/target-exceptions-throw-1.C PR119737 at line 7 (test 
for bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.c++/target-exceptions-throw-1.C (test for 
excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.c++/target-exceptions-throw-1.C 
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.c++/target-exceptions-throw-1.C output pattern test+}

[-XFAIL: libgomp.c++/target-exceptions-throw-2.C (internal compiler error: 
Aborted signal terminated program as)-]
[-XFAIL: libgomp.c++/target-exceptions-throw-2.C PR119737 at line 7 (test 
for bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.c++/target-exceptions-throw-2.C (test for 
excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.c++/target-exceptions-throw-2.C 
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.c++/target-exceptions-throw-2.C output pattern test+}

[-XFAIL: libgomp.oacc-c++/exceptions-throw-1.C -DACC_DEVICE_TYPE_radeon=1 
-DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  (internal compiler error: 
Aborted signal terminated program as)-]
[-XFAIL: libgomp.oacc-c++/exceptions-throw-1.C -DACC_DEVICE_TYPE_radeon=1 
-DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  PR119737 at line 7 (test for 
bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-1.C 
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  
(test for excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-1.C 
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.oacc-c++/exceptions-throw-1.C -DACC_DEVICE_TYPE_radeon=1 
-DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  output pattern test+}

[-XFAIL: libgomp.oacc-c++/exceptions-throw-2.C -DACC_DEVICE_TYPE_radeon=1 
-DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  (internal compiler error: 
Aborted signal terminated program as)-]
[-XFAIL: libgomp.oacc-c++/exceptions-throw-2.C -DACC_DEVICE_TYPE_radeon=1 
-DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  PR119737 at line 9 (test for 
bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-2.C 
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  
(test for excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-2.C 
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.oacc-c++/exceptions-throw-2.C -DACC_DEVICE_TYPE_radeon=1 
-DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2  output pattern test+}

PR target/119737
gcc/
* config/gcn/gcn.cc (gcn_hsa_declare_function_name): Properly
switch sections.
libgomp/
* testsuite/libgomp.c++/target-exceptions-throw-1.C: Remove
PR119737 XFAILing.
* testsuite/libgomp.c++/target-exceptions-throw-2.C: Likewise.
* testsuite/libgomp.oacc-c++/exceptions-throw-1.C: Likewise.
* testsuite/libgomp.oacc-c++/exceptions-throw-2.C: Likewise.

Co-authored-by: Thomas Schwinge 
---
 gcc/config/gcn/gcn.cc | 6 +++---
 libgomp/testsuite/libgomp.c++/target-exceptions-throw-1.C | 3 ---
 libgomp/testsuite/libgomp.c++/target-exceptions-throw-2.C | 3 ---
 libgomp/testsuite/libgomp.oacc-c++/exceptions-throw-1.C   | 3 ---
 libgomp/testsuite/libgomp.oacc-c++/exceptions-throw-2.C   | 3 ---
 5 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index d59e87bed46..91ce8019480 100644
--- a/gcc/config/gcn/gcn.cc
+++ b/gcc/config/gcn/gcn.cc
@@ -6587,8 +6587,8 @@ gcn_hsa_declare_function_name (FILE *file, const char 
*na