[committed] libstdc++: Do not apply localized formatting to NaN and inf [PR114863]

2024-04-26 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

I'm going to push this to gcc-13 and gcc-14 too (approved by Jakub on
IRC).

-- >8 --

We don't want to add grouping to strings like "-inf", and there is no
radix character to replace either.

libstdc++-v3/ChangeLog:

PR libstdc++/114863
* include/std/format (__formatter_fp::format): Only use
_M_localized for finite values.
* testsuite/std/format/functions/format.cc: Check localized
formatting of NaN and initiny.
---
 libstdc++-v3/include/std/format   | 2 +-
 libstdc++-v3/testsuite/std/format/functions/format.cc | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index 22dcb5f24bd..48deba2bcb2 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1734,7 +1734,7 @@ namespace __format
}
 #endif
 
- if (_M_spec._M_localized)
+ if (_M_spec._M_localized && __builtin_isfinite(__v))
{
  __wstr = _M_localize(__str, __expc, __fc.locale());
  if (!__wstr.empty())
diff --git a/libstdc++-v3/testsuite/std/format/functions/format.cc 
b/libstdc++-v3/testsuite/std/format/functions/format.cc
index 4499397aaf9..78cc1ab482a 100644
--- a/libstdc++-v3/testsuite/std/format/functions/format.cc
+++ b/libstdc++-v3/testsuite/std/format/functions/format.cc
@@ -248,6 +248,14 @@ test_locale()
   s = std::format(cloc, "{:05L}", -1.0); // PR libstdc++/110968
   VERIFY( s == "-0001" );
 
+  // PR libstdc++/114863 grouping applied to nan and inf
+  double inf = std::numeric_limits::infinity();
+  s = std::format(eloc, "{0:Le} {0:Lf} {0:Lg}", -inf);
+  VERIFY( s == "-inf -inf -inf" );
+  double nan = std::numeric_limits::quiet_NaN();
+  s = std::format(eloc, "{0:Le} {0:Lf} {0:Lg}", -nan);
+  VERIFY( s == "-nan -nan -nan" );
+
   // Restore
   std::locale::global(cloc);
 }
-- 
2.44.0



[committed, gcc-14] libstdc++: Update status tables to refer to GCC 14 not mainline

2024-04-26 Thread Jonathan Wakely
Pushed to gcc-14.

-- >8 --

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
---
 libstdc++-v3/doc/html/manual/status.html  | 32 +--
 .../doc/xml/manual/status_cxx1998.xml |  4 +--
 .../doc/xml/manual/status_cxx2011.xml |  4 +--
 .../doc/xml/manual/status_cxx2014.xml |  4 +--
 .../doc/xml/manual/status_cxx2017.xml |  4 +--
 .../doc/xml/manual/status_cxx2020.xml |  4 +--
 .../doc/xml/manual/status_cxx2023.xml |  4 +--
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  4 +--
 .../doc/xml/manual/status_cxxtr24733.xml  |  4 +--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 2e293d32f81..c13ec20feaa 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -5,8 +5,8 @@
  NextChapter 1. StatusTable of ContentsImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 2011Implementation Specific 
BehaviorC++ 2014Implementation Specific 
BehaviorFilesystem 
TSC++ 2017Implementation Specific 
BehaviorParallelism 2 
TSC++ 2020C++ 
2023C++ TR1Implementation Specific 
BehaviorC++ TR 24733C++ IS 
29124Implementation Specific 
BehaviorLicenseThe Code: 
GPLThe Documentation: GPL, 
FDLBugsImplementation 
BugsStandard 
BugsImplementation 
StatusC++ 
1998/2003Implementation Status
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
-This section describes the C++ support in mainline GCC, not in any
-particular release.
+This section describes the C++ support in
+the GCC 14 release series, not in any particular release.
 Table 1.1. C++ 1998/2003 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -160,8 +160,8 @@ since that release.
 
 This status table is based on the table of contents of ISO/IEC 14882:2011.
 
-This section describes the C++11 support in mainline GCC, not in any
-particular release.
+This section describes the C++11 support in
+the GCC 14 release series, not in any particular release.
 Table 1.2. C++ 2011 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -433,8 +433,8 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2014.
 Some subclauses are not shown in the table where the content is unchanged
 since C++11 and the implementation is complete.
 
-This section describes the C++14 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++14 and library TS support in
+the GCC 14 release series, not in any particular release.
 Table 1.3. C++ 2014 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -578,8 +578,8 @@ GCC 9.1 was the first release with non-experimental C++17 
support,
 so the API and ABI of features added in C++17 is only stable
 since that release.
 
-This section describes the C++17 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++17 and library TS support in
+the GCC 14 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++17 standard. The "Proposal" column provides a link to the
@@ -1254,8 +1254,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++20 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++20 and library TS support in
+the GCC 14 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++20 standard. The "Proposal" column provides a link to the
@@ -1724,8 +1724,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++23 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++23 and library TS support in
+the GCC 14 release series, not in any particular release.
 
 The following table lists new library features that have been accepted into
 the C++23 working draft. The "Proposal" column provides a link to the
@@ -2212,8 +2212,8 @@ In this implementation the header names are prefixed by
 tr1/, for instance tr1/functional,
 tr1/memory, and so on.
 
-This page describes the TR1 support in mainline GCC, 

[committed, gcc-13] libstdc++: Update status tables to refer to GCC 13 not mainline

2024-04-26 Thread Jonathan Wakely
Pushed to gcc-13.

-- >8 --

This should have been done before the 13.1.0 release.

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
---
 libstdc++-v3/doc/html/manual/status.html  | 32 +--
 .../doc/xml/manual/status_cxx1998.xml |  4 +--
 .../doc/xml/manual/status_cxx2011.xml |  4 +--
 .../doc/xml/manual/status_cxx2014.xml |  4 +--
 .../doc/xml/manual/status_cxx2017.xml |  4 +--
 .../doc/xml/manual/status_cxx2020.xml |  4 +--
 .../doc/xml/manual/status_cxx2023.xml |  4 +--
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  4 +--
 .../doc/xml/manual/status_cxxtr24733.xml  |  4 +--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index af94ead2b82..53957bd2e0d 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -5,8 +5,8 @@
  NextChapter 1. StatusTable of ContentsImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 2011Implementation Specific 
BehaviorC++ 2014Implementation Specific 
BehaviorFilesystem 
TSC++ 2017Implementation Specific 
BehaviorParallelism 2 
TSC++ 2020C++ 
2023C++ TR1Implementation Specific 
BehaviorC++ TR 24733C++ IS 
29124Implementation Specific 
BehaviorLicenseThe Code: 
GPLThe Documentation: GPL, 
FDLBugsImplementation 
BugsStandard 
BugsImplementation 
StatusC++ 
1998/2003Implementation Status
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
-This section describes the C++ support in mainline GCC, not in any
-particular release.
+This section describes the C++ support in
+the GCC 13 release series, not in any particular release.
 Table 1.1. C++ 1998/2003 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -160,8 +160,8 @@ since that release.
 
 This status table is based on the table of contents of ISO/IEC 14882:2011.
 
-This section describes the C++11 support in mainline GCC, not in any
-particular release.
+This section describes the C++11 support in
+the GCC 13 release series, not in any particular release.
 Table 1.2. C++ 2011 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -433,8 +433,8 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2014.
 Some subclauses are not shown in the table where the content is unchanged
 since C++11 and the implementation is complete.
 
-This section describes the C++14 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++14 and library TS support in
+the GCC 13 release series, not in any particular release.
 Table 1.3. C++ 2014 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -578,8 +578,8 @@ GCC 9.1 was the first release with non-experimental C++17 
support,
 so the API and ABI of features added in C++17 is only stable
 since that release.
 
-This section describes the C++17 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++17 and library TS support in
+the GCC 13 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++17 standard. The "Proposal" column provides a link to the
@@ -1254,8 +1254,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++20 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++20 and library TS support in
+the GCC 13 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++20 standard. The "Proposal" column provides a link to the
@@ -1724,8 +1724,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++23 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++23 and library TS support in
+the GCC 13 release series, not in any particular release.
 
 The following table lists new library features that have been accepted into
 the C++23 working draft. The "Proposal" column provides a link to the
@@ -2122,8 +2122,8 @@ In this implementation the header names are prefixed by
 tr1/, for instance tr1/functional,
 tr1/memory, and so on.
 

[committed] libstdc++: Adjust whitespace in status tables in manual

2024-04-26 Thread Jonathan Wakely
Pushed to trunk. I'll also be following this with the non-whitespace
equivalents for the gcc-14 and gcc-13 branches.

-- >8 --

This simplifies the changes needed after branching for a new release, so
that new line breaks don't need to be introduced every time we branch.

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Adjust whitespace.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
---
 libstdc++-v3/doc/html/manual/status.html  | 32 +--
 .../doc/xml/manual/status_cxx1998.xml |  4 +--
 .../doc/xml/manual/status_cxx2011.xml |  4 +--
 .../doc/xml/manual/status_cxx2014.xml |  4 +--
 .../doc/xml/manual/status_cxx2017.xml |  4 +--
 .../doc/xml/manual/status_cxx2020.xml |  4 +--
 .../doc/xml/manual/status_cxx2023.xml |  4 +--
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  4 +--
 .../doc/xml/manual/status_cxxtr24733.xml  |  4 +--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 2e293d32f81..3d55e265272 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -5,8 +5,8 @@
  NextChapter 1. StatusTable of ContentsImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 2011Implementation Specific 
BehaviorC++ 2014Implementation Specific 
BehaviorFilesystem 
TSC++ 2017Implementation Specific 
BehaviorParallelism 2 
TSC++ 2020C++ 
2023C++ TR1Implementation Specific 
BehaviorC++ TR 24733C++ IS 
29124Implementation Specific 
BehaviorLicenseThe Code: 
GPLThe Documentation: GPL, 
FDLBugsImplementation 
BugsStandard 
BugsImplementation 
StatusC++ 
1998/2003Implementation Status
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
-This section describes the C++ support in mainline GCC, not in any
-particular release.
+This section describes the C++ support in
+mainline GCC, not in any particular release.
 Table 1.1. C++ 1998/2003 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -160,8 +160,8 @@ since that release.
 
 This status table is based on the table of contents of ISO/IEC 14882:2011.
 
-This section describes the C++11 support in mainline GCC, not in any
-particular release.
+This section describes the C++11 support in
+mainline GCC, not in any particular release.
 Table 1.2. C++ 2011 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -433,8 +433,8 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2014.
 Some subclauses are not shown in the table where the content is unchanged
 since C++11 and the implementation is complete.
 
-This section describes the C++14 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++14 and library TS support in
+mainline GCC, not in any particular release.
 Table 1.3. C++ 2014 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -578,8 +578,8 @@ GCC 9.1 was the first release with non-experimental C++17 
support,
 so the API and ABI of features added in C++17 is only stable
 since that release.
 
-This section describes the C++17 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++17 and library TS support in
+mainline GCC, not in any particular release.
 
 The following table lists new library features that are included in
 the C++17 standard. The "Proposal" column provides a link to the
@@ -1254,8 +1254,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++20 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++20 and library TS support in
+mainline GCC, not in any particular release.
 
 The following table lists new library features that are included in
 the C++20 standard. The "Proposal" column provides a link to the
@@ -1724,8 +1724,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++23 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++23 and library TS support in
+mainline GCC, not in any particular release.
 
 The following table lists new library features that have been accepted into
 the C++23 working draft. The "Proposal" column provides a link to the
@@ -2212,8 +2212,8 @@ In this implementation the 

[gcc-13 PATCH 2/2 v3] libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

2024-04-25 Thread Jonathan Wakely
On Thu, 18 Apr 2024 at 21:34, Jonathan Wakely wrote:
>
> On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
> >
> > This completes the fixes to put all experimental symbols into
> > libstdc++exp.a.
> >
> > On trunk the libstdc++_libbacktrace.a was removed completely and its
> > contents aded to libstdc++exp.a instead. We don't want to do that on the
> > gcc-13 branch because it will break makefiles using it. We can add the
> > contents to libstdc++exp.a and then install a symlink so that
> > -lstdc++_libbacktrace still works, but links to libstdc++exp.a instead.
>
> It looks like simply duplicating all the libstdc___libbacktrace_FOO
> variables in libbacktrace/Makefile.am does work (see attached patch),
> so that we get an installed libstdc++_libbacktrace.a and a
> not-installed libstdc++_libbacktraceconvenience.a which gets included
> into the installed libstdc++exp.a
>
> So if that's preferable to making the installed
> libstdc++_libbacktrace.a a symlink, we can do that.
>
> I still kinda like the symlink approach, because it reduces the size
> on disk, and the same approach could be used to get rid of
> libstdc++fs.a without breaking makefiles using -lstdc++fs

I committed the symlink approach, but with a slightly different patch
(attached).

This one installs libstdc++_libbacktrace.a as a symlink, but also
removes the .la libtool file for that archive, because I don't think
it's any use. I also added an uninstall-local target so the symlink
gets removed.
commit f3cff718df0cf7590ccf9bc1d8cd17e4e08f1e6d
Author: Jonathan Wakely 
Date:   Thu Apr 18 17:26:55 2024

libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

This completes the fixes to put all experimental symbols into
libstdc++exp.a.

On trunk the libstdc++_libbacktrace.a was removed completely and its
contents aded to libstdc++exp.a instead. We don't want to remove it on
the gcc-13 branch because that would break makefiles using it. We can
add the contents to libstdc++exp.a and then install a symlink so that
using -lstdc++_libbacktrace still works, but links to libstdc++exp.a
instead.

The libstdc++_libbacktrace.la libtool control file is removed by this
change, because I'm pretty sure it's not actually useful, and I don't
know whether it should be a symlink to libstdc++exp.la or a regular file
that refers to libstdc++_libbacktrace.a.

libstdc++-v3/ChangeLog:

* src/experimental/Makefile.am (install-exec-local): New target.
(uninstall-local): New target.
* src/experimental/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.am: Build libstdc++_libbacktrace as
noinst_LTLIBRARIES so it's only a convenience library.
* src/libbacktrace/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/src/experimental/Makefile.am 
b/libstdc++-v3/src/experimental/Makefile.am
index c5a38d882c2..6536e759abd 100644
--- a/libstdc++-v3/src/experimental/Makefile.am
+++ b/libstdc++-v3/src/experimental/Makefile.am
@@ -66,6 +66,15 @@ AM_CXXFLAGS = \
 AM_MAKEFLAGS = \
"gxx_include_dir=$(gxx_include_dir)"
 
+if ENABLE_BACKTRACE
+install-exec-local:
+   -cd '$(DESTDIR)$(toolexeclibdir)' && \
+   $(LN_S) libstdc++exp.a libstdc++_libbacktrace.a
+uninstall-local:
+   -cd '$(DESTDIR)$(toolexeclibdir)' && \
+   rm -f libstdc++_libbacktrace.a
+endif
+
 # Libtool notes
 
 # 1) In general, libtool expects an argument such as `--tag=CXX' when
diff --git a/libstdc++-v3/src/experimental/Makefile.in 
b/libstdc++-v3/src/experimental/Makefile.in
index c16083a7fc8..238c96d9f9a 100644
--- a/libstdc++-v3/src/experimental/Makefile.in
+++ b/libstdc++-v3/src/experimental/Makefile.in
@@ -712,6 +712,8 @@ distclean-generic:
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
+@ENABLE_BACKTRACE_FALSE@install-exec-local:
+@ENABLE_BACKTRACE_FALSE@uninstall-local:
 clean: clean-am
 
 clean-am: clean-generic clean-libtool clean-toolexeclibLTLIBRARIES \
@@ -740,7 +742,7 @@ install-dvi: install-dvi-am
 
 install-dvi-am:
 
-install-exec-am: install-toolexeclibLTLIBRARIES
+install-exec-am: install-exec-local install-toolexeclibLTLIBRARIES
 
 install-html: install-html-am
 
@@ -779,7 +781,7 @@ ps: ps-am
 
 ps-am:
 
-uninstall-am: uninstall-toolexeclibLTLIBRARIES
+uninstall-am: uninstall-local uninstall-toolexeclibLTLIBRARIES
 
 .MAKE: install-am install-strip
 
@@ -789,18 +791,25 @@ uninstall-am: uninstall-toolexeclibLTLIBRARIES
distclean-libtool distclean-tags dvi dvi-am html html-am info \
info-am install install-am install-data install-data-am \
install-dvi install-dvi-am install-exec install-exec-am \
-   install-html install-html-am install-info

[committed] libstdc++: Rename man pages to use '::' instead of '_'

2024-04-25 Thread Jonathan Wakely
Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

The Doxygen-generated man pages for some new types need to be renamed to
use '::' instead of '_' in the filenames.

libstdc++-v3/ChangeLog:

* scripts/run_doxygen: Rename man pages for nested types.
---
 libstdc++-v3/scripts/run_doxygen | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libstdc++-v3/scripts/run_doxygen b/libstdc++-v3/scripts/run_doxygen
index ea9bcb56553..11f24b058af 100644
--- a/libstdc++-v3/scripts/run_doxygen
+++ b/libstdc++-v3/scripts/run_doxygen
@@ -415,8 +415,21 @@ for f in __cxxabiv1_*; do
 mv $f $newname
 done
 
+mv std::__unspecified___exception_ptr.3 std::exception_ptr.3
+
 # Then piecemeal nested classes
 
+for f in std*distribution_param_type.3; do
+newname=`echo $f | sed 
's/distribution_param_type/distribution::param_type/'`
+mv $f $newname
+done
+
+for f in std*filesystem::path_iterator.3; do
+newname=`echo $f | sed 's/path_iterator/path::iterator/'`
+mv $f $newname
+done
+
+mv std::chrono::tzdb_list_const_iterator.3 
std::chrono::tzdb_list::const_iterator.3
 
 # Generic removal bits, where there are things in the generated man
 # pages that need to be killed.
-- 
2.44.0



[committed] libstdc++: Fix run_doxygen for Doxygen 1.10 man page format

2024-04-25 Thread Jonathan Wakely
Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

Doxygen switched from \fC to \fR in its man page output:
https://github.com/doxygen/doxygen/pull/10497

This breaks our script that expects \fC so change the regaulr expression
to work with either style.

libstdc++-v3/ChangeLog:

* scripts/run_doxygen: Adjust sed pattern to match '\fR' for
new man output that Doxygen 1.10 generates.
---
 libstdc++-v3/scripts/run_doxygen | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/scripts/run_doxygen b/libstdc++-v3/scripts/run_doxygen
index fbd601b11cc..ea9bcb56553 100644
--- a/libstdc++-v3/scripts/run_doxygen
+++ b/libstdc++-v3/scripts/run_doxygen
@@ -294,7 +294,11 @@ $gxx $cppflags $cxxflags 
${srcdir}/doc/doxygen/stdheader.cc -o ./stdheader || ex
 problematic=`grep -E -l '#include <.*h>' [a-z]*.3`
 for f in $problematic; do
 # this is also slow, but safe and easy to debug
-oldh=`sed -n '/fC#include .*/\1/p' $f`
+oldh=`sed -n '/f[CR]#include .*/\1/p' $f`
+if [ "$oldh" == "" ]; then
+  echo "ERROR: Doxygen man page formatting changed" 2>&1
+  continue
+fi
 newh=`echo $oldh | sed 's/&\\././g' | ./stdheader`
 sed "s=${oldh/\\/.}=${newh}=" $f > TEMP && mv TEMP $f
 done
-- 
2.44.0



[committed] libstdc++: Fix typo in Doxygen comment

2024-04-25 Thread Jonathan Wakely
Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/chrono (tzdb_list): Fix typo in Doxygen comment.
---
 libstdc++-v3/include/std/chrono | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 3a9751781d2..b0aadf83b03 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -2780,7 +2780,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /** Remove the tzdb object _after_ the one the iterator refers to.
*
-   * Calling this function concurently with any of `front()`, `begin()`,
+   * Calling this function concurrently with any of `front()`, `begin()`,
* or `end()` does not cause a data race, but in general this function
* is not thread-safe. The behaviour may be undefined if erasing an
* element from the list while another thread is calling the same
-- 
2.44.0



[committed] libstdc++: Update Doxygen config for new headers

2024-04-25 Thread Jonathan Wakely
Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* doc/doxygen/stdheader.cc (init_map): Add missing headers.
* doc/doxygen/user.cfg.in (EXCLUDE): Exclude generated files for
std::format and std::text_encoding.
---
 libstdc++-v3/doc/doxygen/stdheader.cc | 42 ---
 libstdc++-v3/doc/doxygen/user.cfg.in  |  6 
 2 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/libstdc++-v3/doc/doxygen/stdheader.cc 
b/libstdc++-v3/doc/doxygen/stdheader.cc
index 67f54eef02b..3ee825feb66 100644
--- a/libstdc++-v3/doc/doxygen/stdheader.cc
+++ b/libstdc++-v3/doc/doxygen/stdheader.cc
@@ -40,19 +40,25 @@ void init_map()
 headers["ranges_algo.h"]= "algorithm";
 headers["ranges_algobase.h"]= "algorithm";
 headers["heap.h"]   = "algorithm";
+headers["chrono_io.h"]  = "chrono";
+headers["parse_numbers.h"]  = "chrono";
 headers["exception_ptr.h"]  = "exception";
 headers["nested_exception.h"]   = "exception";
 headers["fs_dir.h"] = "filesystem";
 headers["fs_fwd.h"] = "filesystem";
 headers["fs_ops.h"] = "filesystem";
 headers["fs_path.h"]= "filesystem";
+headers["unicode.h"]= "format";
+headers["unicode-data.h"]   = "format";
 headers["binders.h"]= "functional";
 headers["function.h"]   = "functional";
 headers["functional_hash.h"]= "functional";
 headers["mofunc_impl.h"]= "functional";
 headers["move_only_function.h"] = "functional";
 headers["invoke.h"] = "functional";
+headers["ranges_cmp.h"] = "functional";
 headers["refwrap.h"]= "functional";
+headers["elements_of.h"]= "generator";
 headers["quoted_string.h"]  = "iomanip";
 headers["ios_base.h"]   = "ios";
 headers["basic_ios.h"]  = "ios";
@@ -64,6 +70,7 @@ void init_map()
 headers["stream_iterator.h"]= "iterator";
 headers["streambuf_iterator.h"] = "iterator";
 headers["iterator_concepts.h"]  = "iterator";
+headers["max_size_type.h"]  = "iterator";
 headers["range_access.h"]   = "iterator";
 headers["codecvt.h"]= "locale";
 headers["c++locale.h"]  = "locale";
@@ -80,9 +87,11 @@ void init_map()
 headers["memoryfwd.h"]  = "memory";
 headers["align.h"]  = "memory";
 headers["alloc_traits.h"]   = "memory";
+headers["allocated_ptr.h"]  = "memory";
 headers["auto_ptr.h"]  = "memory";
 headers["construct.h"]  = "memory";
 headers["allocator.h"]  = "memory";
+headers["new_allocator.h"]  = "memory";
 headers["raw_storage_iter.h"]   = "memory";
 headers["tempbuf.h"]= "memory";
 headers["uninitialized.h"]  = "memory";
@@ -94,11 +103,15 @@ void init_map()
 headers["ptr_traits.h"] = "memory";
 headers["uses_allocator.h"] = "memory";
 headers["uses_allocator_args.h"]= "memory";
+headers["out_ptr.h"]= "memory";
+headers["memory_resource.h"]= "memory_resource";
 headers["unique_lock.h"]= "mutex";
+headers["sat_arith.h"]  = "numeric";
+headers["ostream_insert.h"] = "ostream";
 headers["uniform_int_dist.h"]   = "random";
 headers["ranges_base.h"]= "ranges";
+headers["ranges_to.h"]  = "ranges";
 headers["ranges_util.h"]= "ranges";
-headers["ranges_cmp.h"] = "functional";
 headers["regex_automaton.h"]= "regex";
 headers["regex_automaton.tcc"]  = "regex";
 headers["regex_compiler.h"] = "regex";
@@ -122,6 +135,9 @@ void init_map()
 headers["string_view.tcc"]  = "string_view";
 headers["this_thread_sleep.h"]  = "thread";
 headers["tree.h"]   = "map";
+headers["hashtable.h"]  = "unordered_map";
+headers["hashtable_policy.h"]   = "unordered_map";
+headers["move.h"]   = "utility";
 headers["pair.h"]   = "utility";
 headers["relops.h"] = "utility";
 headers["gslice.h"] = "valarray";
@@ -142,30 +158,34 @@ void init_map()
 headers["abs.h"]= "cstdlib";
 headers["specfun.h"]= "cmath";
 
-// This list is complete as of the October 2021 working draft.
+// This list is complete as of the April 2024 working draft.
 std_headers = {
"algorithm", "any", "array", "atomic",
"barrier", "bit", "bitset",
"charconv", "chrono", "codecvt", "compare", 

[committed] libstdc++: Add comment to #include in

2024-04-25 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

It's not obvious why  needs  so add a
comment to it.

libstdc++-v3/ChangeLog:

* include/std/variant: Add comment to #include.
---
 libstdc++-v3/include/std/variant | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index f79d95db7a8..748e9bae1cb 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -42,7 +42,7 @@
 #include 
 #include 
 #include 
-#include 
+#include  // _Select_int
 #include 
 #include 
 #include  // in_place_index_t
-- 
2.44.0



Re: [gcc-13 PATCH 1/2] libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbols

2024-04-25 Thread Jonathan Wakely
Pushed to gcc-13

On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely  wrote:
>
> In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
> all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
> but that wasn't true. Only the symbols from the latter were added to
> libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
> libtool won't combine static libs that are going to be installed
> separately. Because libstdc++fs.a is still installed, libtool decides it
> shouldn't be included in libstdc++exp.a.
>
> The solution is similar to what we already do for libsupc++.a: build two
> static libs, libstdc++fs.a and libstdc++fsconvenience.a, where the
> former is installed and the latter isn't. If we then tell libtool to
> include the latter in libstdc++exp.a it will do as it's told.
>
> libstdc++-v3/ChangeLog:
>
> * src/experimental/Makefile.am: Use libstdc++fsconvenience.a
> instead of libstdc++fs.a.
> * src/experimental/Makefile.in: Regenerate.
> * src/filesystem/Makefile.am: Build libstdc++fsconvenience.a as
> well.
> * src/filesystem/Makefile.in: Regenerate.
>
> (cherry picked from commit abf40d2953639534af3428424f467adf3cb52177)
> ---
>  libstdc++-v3/src/experimental/Makefile.am |  2 +-
>  libstdc++-v3/src/experimental/Makefile.in |  4 +--
>  libstdc++-v3/src/filesystem/Makefile.am   |  4 +++
>  libstdc++-v3/src/filesystem/Makefile.in   | 37 +++
>  4 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/src/experimental/Makefile.am 
> b/libstdc++-v3/src/experimental/Makefile.am
> index 1c7cea7e846..c5a38d882c2 100644
> --- a/libstdc++-v3/src/experimental/Makefile.am
> +++ b/libstdc++-v3/src/experimental/Makefile.am
> @@ -25,7 +25,7 @@ include $(top_srcdir)/fragment.am
>  toolexeclib_LTLIBRARIES = libstdc++exp.la
>
>  if ENABLE_FILESYSTEM_TS
> -filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fs.la
> +filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
>  else
>  filesystem_lib =
>  endif
> diff --git a/libstdc++-v3/src/experimental/Makefile.in 
> b/libstdc++-v3/src/experimental/Makefile.in
> index 6f6b742c1cf..c16083a7fc8 100644
> --- a/libstdc++-v3/src/experimental/Makefile.in
> +++ b/libstdc++-v3/src/experimental/Makefile.in
> @@ -148,7 +148,7 @@ am__uninstall_files_from_dir = { \
>}
>  am__installdirs = "$(DESTDIR)$(toolexeclibdir)"
>  LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
> -@ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = 
> $(top_builddir)/src/filesystem/libstdc++fs.la
> +@ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = 
> $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
>  @ENABLE_BACKTRACE_TRUE@am__DEPENDENCIES_2 = 
> $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
>  am__objects_1 = contract.lo
>  am_libstdc__exp_la_OBJECTS = $(am__objects_1)
> @@ -450,7 +450,7 @@ WARN_CXXFLAGS = \
>  AM_CPPFLAGS = $(GLIBCXX_INCLUDES) $(CPPFLAGS)
>  toolexeclib_LTLIBRARIES = libstdc++exp.la
>  @ENABLE_FILESYSTEM_TS_FALSE@filesystem_lib =
> -@ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = 
> $(top_builddir)/src/filesystem/libstdc++fs.la
> +@ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = 
> $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
>  @ENABLE_BACKTRACE_FALSE@backtrace_lib =
>  @ENABLE_BACKTRACE_TRUE@backtrace_lib = 
> $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
>  headers =
> diff --git a/libstdc++-v3/src/filesystem/Makefile.am 
> b/libstdc++-v3/src/filesystem/Makefile.am
> index d2e1fde3f13..55f309b5c15 100644
> --- a/libstdc++-v3/src/filesystem/Makefile.am
> +++ b/libstdc++-v3/src/filesystem/Makefile.am
> @@ -22,7 +22,10 @@
>
>  include $(top_srcdir)/fragment.am
>
> +# Separate libstdc++fs.a to be installed.
>  toolexeclib_LTLIBRARIES = libstdc++fs.la
> +# Duplicate lib that is to be part of libstdc++exp.a
> +noinst_LTLIBRARIES = libstdc++fsconvenience.la
>
>  headers =
>
> @@ -44,6 +47,7 @@ sources = \
>  # vpath % $(top_srcdir)/src/filesystem
>
>  libstdc__fs_la_SOURCES = $(sources)
> +libstdc__fsconvenience_la_SOURCES = $(sources)
>
>  # AM_CXXFLAGS needs to be in each subdirectory so that it can be
>  # modified in a per-library or per-sub-library way.  Need to manually
> diff --git a/libstdc++-v3/src/filesystem/Makefile.in 
> b/libstdc++-v3/src/filesystem/Makefile.in
> index 852390ec1a9..76ba905087b 100644
> --- a/libstdc++-v3/src/filesystem/Makefile.in
> +++ b/libstdc++-v3/src/filesystem/Makefile.in
> @@ -147,7 +147,7 @@ am__uninstall_files_from_dir = { \
>   $(am__cd) "$$dir" && rm -f $$files; }; \
>}
>  am__installdirs = "$(DEST

Re: [PATCH] c++, v2: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

2024-04-24 Thread Jonathan Wakely
On Tue, 23 Apr 2024 at 17:05, Jakub Jelinek  wrote:
>
> On Mon, Apr 22, 2024 at 11:14:35PM -0400, Jason Merrill wrote:
> > > > The following testcase regressed with Marek's r14-5979 change,
> > > > when pr113208_0.C is compiled where the ctor is marked constexpr,
> > > > we no longer perform this optimization, where
> > > > _ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
> > > > _ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
> > > > _ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
> > > > instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
> > > > _ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
> > > > content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
> > > > _ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
> >
> > This seems like an ABI bug that could use a non-LTO testcase.
>
> Well, except for the issues it causes to LTO I think it is compatible,
> worst case we get the body of the ctor duplicated in the executable
> and the linker picks some of the weak symbols as the symbol definitions.
> Anyway, I've added a non-LTO testcase for that in the patch below.
>
> > Hmm, cloning the bodies and then discarding them later seems like more extra
> > work than creating the cgraph nodes.
>
> So, I've tried to handle that in tentative_decl_linkage, like that function
> already handles functions declared inline except for implicit template
> instantiations.  If we expect that import_export_decl will do comdat_linkage
> for the ctor later on do it right away.
>
> That fixes the testcases too, but seems to regress
> +FAIL: libstdc++-abi/abi_check
> on both x86_64-linux and i686-linux, in each case 8 symbols disappeared from
> libstdc++.so.6:
> _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev
> _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev
> _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev
> _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev
> _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev
> _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev
> _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev
> _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev
>
> Will need to study why that happened, it might be that it was ok because
> I think the filesystem stuff is unlike the rest compiled with no exported
> templates, but would need at least some hacks in libstdc++ to preserve
> previously exported symbols.

There are explicit instantiation definitions that should instantiate
those types:

src/c++17/fs_dir.cc:template class std::__shared_ptr;
src/c++17/fs_dir.cc:template class
std::__shared_ptr;
src/c++17/fs_path.cc:template class std::__shared_ptr;

So the missing symbols should be present in cow-fs_dir.o and cow-fs_path.o



> Still, feels like a risky change this late if it wouldn't break ABI of other
> libraries.
>
> 2024-04-23  Jakub Jelinek  
>
> PR lto/113208
> * decl2.cc (tentative_decl_linkage): Use comdat_linkage also
> for implicit instantiations of maybe in charge ctors/dtors
> if -fimplicit-templates or -fimplicit-inline-templates and
> -fweak and target supports aliases.
>
> * g++.dg/abi/comdat2.C: New test.
> * g++.dg/lto/pr113208_0.C: New test.
> * g++.dg/lto/pr113208_1.C: New file.
> * g++.dg/lto/pr113208.h: New file.
>
> --- gcc/cp/decl2.cc.jj  2024-04-22 15:16:55.328548807 +0200
> +++ gcc/cp/decl2.cc 2024-04-23 09:52:18.993250442 +0200
> @@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl)
>  to mark the functions at this point.  */
>   if (DECL_DECLARED_INLINE_P (decl)
>   && (!DECL_IMPLICIT_INSTANTIATION (decl)
> - || DECL_DEFAULTED_FN (decl)))
> + || DECL_DEFAULTED_FN (decl)
> + /* For implicit instantiations of cdtors,
> +if import_export_decl would use comdat linkage,
> +make sure to use it right away, so that maybe_clone_body
> +can use aliases.  See PR113208.  */
> + || (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl)
> + && (flag_implicit_templates
> + || flag_implicit_inline_templates)
> + && flag_weak
> + && TARGET_SUPPORTS_ALIASES)))
> {
>   /* This function must have external linkage, as
>  otherwise DECL_INTERFACE_KNOWN would have been
> --- gcc/testsuite/g++.dg/abi/comdat2.C.jj   2024-04-23 10:04:28.485964610 
> +0200
> +++ gcc/testsuite/g++.dg/abi/comdat2.C  2024-04-23 10:05:24.757171194 +0200
> @@ -0,0 +1,26 

Re: [PATCH] Spelling fixes for translatable strings

2024-04-23 Thread Jonathan Wakely
On Mon, 22 Apr 2024 at 22:30, Jakub Jelinek  wrote:
>
> Hi!
>
> I've run aspell on gcc.pot (just quickly skimming, so pressing
> I key hundreds of times and just stopping when I catch something that
> looks like a misspelling).
>
> I plan to commit this tomorrow as obvious unless somebody finds some
> issues in it, you know, I'm not a native English speaker.
> Yes, I know favour is valid UK spelling, but we spell the US way I think.

Yup:
https://gcc.gnu.org/codingconventions.html#Spelling

> I've left some *ise* -> *ize* cases (recognise, initialise), those
> had too many hits, though in translatable strings just 4, so maybe
> worth changing too:
> msgid "recognise the specified suffix as a definition module filename"
> msgid "recognise the specified suffix as implementation and module filenames"
> "initialiser for a dylib."
> msgid "%qE attribute argument %qE is not recognised"

That spelling is explicitly mentioned at the link above, so they
should be "ize" really.

> 2024-04-22  Jakub Jelinek  
>
> * config/epiphany/epiphany.opt (may-round-for-trunc): Spelling fix:
> floatig -> floating.
> * config/riscv/riscv.opt (mcsr-check): Spelling fix: CRS -> CSR.
> * params.opt (-param=ipa-cp-profile-count-base=): Spelling fix:
> frequncy -> frequency.
> gcc/c-family/
> * c.opt (Wstrict-flex-arrays): Spelling fix: inproper -> improper.
> gcc/cp/
> * parser.cc (cp_parser_using_declaration): Spelling fix: favour
>     -> favor.
> gcc/m2/
> * lang.opt (fuse-list=): Spelling fix: finalializations ->
> finalizations.

LGTM

+Reviewed-by: Jonathan Wakely 



Re: [PATCH] libstdc++: Silence irrelevant warnings in

2024-04-22 Thread Jonathan Wakely
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz  wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?

OK, thanks


>
> - 8< -
>
>
> Avoid
> -Wnarrowing in C code;
> -Wtautological-compare in unconditional static_assert (necessary for
> faking a dependency on a template parameter)
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd.h: Ignore -Wnarrowing for
> arm_neon.h.
> (__int_for_sizeof): Replace tautological compare with checking
> for invalid template parameter value.
> * include/experimental/bits/simd_builtin.h (__extract_part):
> Remove tautological compare by combining two static_assert.
> ---
>  libstdc++-v3/include/experimental/bits/simd.h | 8 +++-
>  libstdc++-v3/include/experimental/bits/simd_builtin.h | 3 +--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd.h b/libstdc++-v3/
> include/experimental/bits/simd.h
> index 03c2e17a326..6ef9c955cfa 100644
> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -44,7 +44,12 @@
>  #if _GLIBCXX_SIMD_X86INTRIN
>  #include 
>  #elif _GLIBCXX_SIMD_HAVE_NEON
> +#pragma GCC diagnostic push
> +// narrowing conversion of '__a' from 'uint64_t' {aka 'long long unsigned
> int'} to
> +//   'int64x1_t' {aka 'long long int'} [-Wnarrowing]
> +#pragma GCC diagnostic ignored "-Wnarrowing"
>  #include 
> +#pragma GCC diagnostic pop
>  #endif
>  #if _GLIBCXX_SIMD_HAVE_SVE
>  #include 
> @@ -598,6 +603,7 @@ struct __is_bitmask
>constexpr auto
>__int_for_sizeof()
>{
> +static_assert(_Bytes > 0);
>  if constexpr (_Bytes == sizeof(int))
>return int();
>#ifdef __clang__
> @@ -663,7 +669,7 @@ struct _Ip
> return _Ip{};
>}
>  else
> -  static_assert(_Bytes != _Bytes, "this should be unreachable");
> +  static_assert(_Bytes == 0, "this should be unreachable");
>}
>  #pragma GCC diagnostic pop
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc+
> +-v3/include/experimental/bits/simd_builtin.h
> index af0c4886108..49c7c7e1c70 100644
> --- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
> +++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
> @@ -278,8 +278,7 @@ __extract_part(const _SimdWrapper<_Tp, _Np> __x)
>__extract_part(const _SimdWrapper __x)
>{
>  static_assert(_Combine == 1, "_Combine != 1 not implemented");
> -static_assert(__have_avx512f && _Np == _Np);
> -static_assert(_Total >= 2 && _Index + _Combine <= _Total && _Index >= 0);
> +static_assert(__have_avx512f && _Total >= 2 && _Index + _Combine <=
> _Total && _Index >= 0);
>  return __x._M_data >> (_Index * _Np / _Total);
>}
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──
>



Re: [PATCH] libstdc++: Fix conversion of simd to vector builtin

2024-04-22 Thread Jonathan Wakely
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz  wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?

OK


>
> - 8< -
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/114803
> * include/experimental/bits/simd_builtin.h
> (_SimdBase2::operator __vector_type_t): There is no __builtin()
> function in _SimdWrapper, instead use its conversion operator.
> * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New
> test.
> ---
>  .../include/experimental/bits/simd_builtin.h  |   2 +-
>  .../simd/pr114803_vecbuiltin_cvt.cc   | 105 ++
>  2 files changed, 106 insertions(+), 1 deletion(-)
>  create mode 100644 libstdc++-v3/testsuite/experimental/simd/
> pr114803_vecbuiltin_cvt.cc
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc+
> +-v3/include/experimental/bits/simd_builtin.h
> index 49c7c7e1c70..4ceeb423894 100644
> --- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
> +++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
> @@ -841,7 +841,7 @@ struct _SimdBase2
>
>_GLIBCXX_SIMD_ALWAYS_INLINE explicit
>operator __vector_type_t<_Tp, _Np>() const
> -  { return static_cast*>(this)-
> >_M_data.__builtin(); }
> +  { return __data(*static_cast*>(this)); }
>  };
>
>  struct _SimdBase1
> diff --git a/libstdc++-v3/testsuite/experimental/simd/
> pr114803_vecbuiltin_cvt.cc b/libstdc++-v3/testsuite/experimental/simd/
> pr114803_vecbuiltin_cvt.cc
> new file mode 100644
> index 000..103dd19394c
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc
> @@ -0,0 +1,105 @@
> +// { dg-options "-std=gnu++17" }
> +// { dg-do compile { target c++17 } }
> +
> +#include 
> +
> +template 
> +  void
> +  maybe_test()
> +  {
> +using V = std::experimental::simd std::experimental::simd_abi::_VecBuiltin<16>>;
> +if constexpr (std::is_destructible_v)
> +  {
> +   using V2 [[gnu::vector_size(16)]] = T;
> +   V x = {};
> +   V2 x2 = static_cast(x);
> +   x = static_cast(x2);
> +   for (unsigned i = 0; i < V::size(); ++i)
> + {
> +   if (x2[i] != 0)
> + __builtin_abort();
> + }
> +#ifdef __SSE__
> +   if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__m128>(x));
> +   else if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__m128d>(x));
> +   else if constexpr (std::is_integral_v)
> + x = static_cast(static_cast<__m128i>(x));
> +#elif __ALTIVEC__
> +   if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__vector float>(x));
> +#ifdef __VSX__
> +   else if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__vector double>(x));
> +#endif
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(signed char)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed char>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(signed char))
> + x = static_cast(static_cast<__vector unsigned char>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(short)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed short>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(short))
> + x = static_cast(static_cast<__vector unsigned short>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(int)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed int>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(int))
> + x = static_cast(static_cast<__vector unsigned int>(x));
> +#ifdef __VSX__
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(long
> long)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed long long>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(long
> long))
> + x = static_cast(static_cast<__vector unsigned long long>(x));
> +#endif
> +#elif __ARM_NEON
> +   if constexpr (std::is_same_v)
> + x = static_cast(static_cast(x));
> +#ifdef __aarch64__
> +   else if constexpr (std::is_same_v)
> + x = static_cast(static_cast(x));
> +#endif
> +   else if constexpr (std::is_integral_v && sizeof(T) == 1 &&
> std::is_signed_v)
> + x = static_cast(static_cast(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == 1)
> + x = static_cast(static_cast(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == 2 &&
> std::is_signed_v)
> + x 

Re: [PATCH] libstdc++: Workaround kernel-headers on s390x-linux

2024-04-22 Thread Jonathan Wakely
On Mon, 22 Apr 2024 at 16:37, Jakub Jelinek  wrote:
>
> Hi!
>
> We see
> FAIL: 17_intro/headers/c++1998/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2011/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2014/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2017/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2020/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/names.cc  -std=gnu++17 (test for excess errors)
> on s390x-linux.
> The first 5 are due to kernel-headers not using uglified attribute names,
> where  contains
> __attribute__((packed, aligned(4)))
> I've filed a downstream bugreport for this in
> https://bugzilla.redhat.com/show_bug.cgi?id=2276084
> (not really sure where to report kernel-headers issues upstream), while the
> last one is due to  from glibc containing:
>   #ifdef __USE_MISC
>   # define __ctx(fld) fld
>   #else
>   # define __ctx(fld) __ ## fld
>   #endif
>   ...
>   typedef union
> {
>   double  __ctx(d);
>   float   __ctx(f);
> } fpreg_t;
> and g++ predefining -D_GNU_SOURCE which implies define __USE_MISC.
>
> The following patch adds a workaround for this on the libstdc++ testsuite
> side, ok for trunk?

OK, thanks.


>
> 2024-04-22  Jakub Jelinek  
>
> * testsuite/17_intro/names.cc (d, f): Undefine on s390*-linux*.
> * testsuite/17_intro/headers/c++1998/all_attributes.cc (packed): Don't
> define on s390.
> * testsuite/17_intro/headers/c++2011/all_attributes.cc (packed):
> Likewise.
> * testsuite/17_intro/headers/c++2014/all_attributes.cc (packed):
> Likewise.
> * testsuite/17_intro/headers/c++2017/all_attributes.cc (packed):
> Likewise.
> * testsuite/17_intro/headers/c++2020/all_attributes.cc (packed):
> Likewise.
>
> --- libstdc++-v3/testsuite/17_intro/names.cc.jj 2024-02-02 22:13:29.575359165 
> +0100
> +++ libstdc++-v3/testsuite/17_intro/names.cc2024-04-22 16:54:35.696710752 
> +0200
> @@ -270,6 +270,12 @@
>  #undef u
>  #endif
>
> +#if defined (__linux__) && defined (__s390__)
> +//  defines fpreg_t::d and fpreg_t::f
> +#undef d
> +#undef f
> +#endif
> +
>  #if defined (__linux__) && defined (__sparc__)
>  #undef y
>  #endif
> --- libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc.jj  
>   2024-01-03 12:08:09.603789437 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc   
> 2024-04-22 17:11:04.734990469 +0200
> @@ -29,7 +29,11 @@
>  # define noreturn 1
>  # define visibility 1
>  #endif
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc.jj  
>   2024-04-22 17:11:20.028805205 +0200
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc   
> 2024-04-22 17:12:01.531302456 +0200
> @@ -29,7 +29,11 @@
>  # define visibility 1
>  #endif
>  #define no_unique_address 1
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc.jj  
>   2024-01-03 12:08:09.556790095 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc   
> 2024-04-22 17:12:20.630071099 +0200
> @@ -29,7 +29,11 @@
>  # define visibility 1
>  #endif
>  #define no_unique_address 1
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc.jj  
>   2024-01-03 12:08:09.506790795 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc   
> 2024-04-22 17:12:38.751851577 +0200
> @@ -28,7 +28,11 @@
>  # define visibility 1
>  #endif
>  #define no_unique_address 1
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc.jj  
>   2024-01-03 12:08:09.502790851 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc   
> 2024-04-22 17:12:56.043642110 +0200
> @@ -27,7 +27,11 @@
>  # define cold 1
>  # define visibility 1
>  #endif
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 

[PATCH][wwwdocs] Improve grammar for AVR changes in GCC 14

2024-04-22 Thread Jonathan Wakely
OK for wwwdocs?


---
 htdocs/gcc-14/changes.html | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..21d33db8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -696,13 +696,13 @@ a work-in-progress.
 AVR
 
   On AVR64* and AVR128* devices, read-only data is now located in program
-memory per default and no more in RAM.
+memory per default and no longer in RAM.
 
   Only a 32KiB block of program memory can be used to store
and access .rodata in that way. Which block is used can be selected
-   by defining symbol __flmap.
+   by defining the symbol __flmap.
As an alternative, the byte address of the block can be specified
-   by symbol __RODATA_FLASH_START__ which takes
+   by the symbol __RODATA_FLASH_START__ which takes
precedence over __flmap.
For example, linking with
-Wl,--defsym,__RODATA_FLASH_START__=32k
@@ -715,9 +715,9 @@ a work-in-progress.
href="https://github.com/avrdudes/avr-libc/issues/931;>#931
can be used. The latter initializes NVMCTRL_CTRLB.FLMAP
in the startup code and according to the value
-   of__flmap resp.
+   of__flmap or
__RODATA_FLASH_START__.
-  When AVR-LibC with#931 is used, then defining symbol
+  When AVR-LibC with#931 is used, then defining the symbol
__flmap_lock to a non-zero value will set bit
NVMCTRL_CTRLB.FLMAPLOCK. This will protect
NVMCTRL_CTRLB.FLMAP from any further changes 
@@ -726,7 +726,7 @@ a work-in-progress.
can be used:
 __asm (".global __flmap_lock"  "\n\t"
"__flmap_lock = 1");
-  When you do not want the code from#931, then define global
+  When you do not want the code from#931, then define a global
symbol __do_flmap_init and the linker will not pull in
that code from libmcu.a any more.
   In order to return to the old placement of read-only data in RAM,
@@ -736,7 +736,7 @@ __asm (".global __flmap_lock"  "\n\t"
  functionality.
   
   Read-only data is located in output section .rodata,
-   wheras it is part of .text when located in RAM.
+   whereas it is part of .text when located in RAM.
   The feature is only available when the compiler is configured
with a version of Binutils that implements
https://sourceware.org/PR31124;>PR31124, which is the
@@ -784,7 +784,7 @@ __asm (".global __flmap_lock"  "\n\t"
   
 On the Reduced Tiny devices,
 the meaning of register constraint"w" has been changed.
-It containts now the registers R24R31 like it is the case for all
+It now constrains the registers R24R31 as is the case for all
 the other devices.
   
 
-- 
2.44.0



[committed] libstdc++: Simplify constraints on <=> for std::reference_wrapper

2024-04-19 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

Instead of constraining these overloads in terms of synth-three-way we
can just check that the value_type is less-than-comparable, which is
what synth-three-way's constraints check.

The reason that I implemented these with constraints has now been filed
as LWG 4071, so add a comment about that too.

libstdc++-v3/ChangeLog:

* include/bits/refwrap.h (operator<=>): Simplify constraints.
---
 libstdc++-v3/include/bits/refwrap.h | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/bits/refwrap.h 
b/libstdc++-v3/include/bits/refwrap.h
index fd1cc2b63e6..71ec2b297b7 100644
--- a/libstdc++-v3/include/bits/refwrap.h
+++ b/libstdc++-v3/include/bits/refwrap.h
@@ -384,23 +384,29 @@ _GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, true_type)
&& requires { { __x.get() == __y.get() } -> convertible_to; }
   { return __x.get() == __y.get(); }
 
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 4071. reference_wrapper comparisons are not SFINAE-friendly
+
   [[nodiscard]]
   friend constexpr auto
-  operator<=>(reference_wrapper __x, reference_wrapper<_Tp> __y)
-  requires requires { __detail::__synth3way(__x.get(), __y.get()); }
+  operator<=>(reference_wrapper __x, reference_wrapper __y)
+  requires requires (const _Tp __t) {
+   { __t < __t } -> __detail::__boolean_testable;
+  }
   { return __detail::__synth3way(__x.get(), __y.get()); }
 
   [[nodiscard]]
   friend constexpr auto
   operator<=>(reference_wrapper __x, const _Tp& __y)
-  requires requires { __detail::__synth3way(__x.get(), __y); }
+  requires requires { { __y < __y } -> __detail::__boolean_testable; }
   { return __detail::__synth3way(__x.get(), __y); }
 
   [[nodiscard]]
   friend constexpr auto
   operator<=>(reference_wrapper __x, reference_wrapper __y)
-  requires (!is_const_v<_Tp>)
-   && requires { __detail::__synth3way(__x.get(), __y.get()); }
+  requires (!is_const_v<_Tp>) && requires (const _Tp __t) {
+   { __t < __t } -> __detail::__boolean_testable;
+  }
   { return __detail::__synth3way(__x.get(), __y.get()); }
 #endif
 };
-- 
2.44.0



Re: [PATCH] libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]

2024-04-19 Thread Jonathan Wakely
On Fri, 19 Apr 2024 at 10:08, Jonathan Wakely  wrote:
>
> On Fri, 19 Apr 2024 at 07:14, Richard Biener  
> wrote:
> >
> > On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely  wrote:
> > >
> > > This would fix the but, how do people feel about it this close to the
> > > gcc-14 release?
> >
> > Guess we'll have to fix it anyway, so why not now ...
>
> Yeah, I don't think Debian is going to stop using this feature, and it
> might get used more widely in future (it's currently part of the
> "vanguard" format for tzdata, but might move to "main" one day and
> then all distros would have chained links). So it needs to be
> backported to gcc-13 too.
>
> > (what could go wrong..)
>
> Well the risk is that my new code doesn't correctly detect cycles, and
> so could go into an infinite loop when trying to follow chained links.
> The current code on trunk will just fail to find a time_zone and throw
> an exception, which is not ideal, but predictable and easily
> understood. Attempting to handle chained links adds complexity.
>
> I think my new code is correct so that it won't get stuck in a loop,
> and there are tests which should cover it sufficiently. And for
> correctly tzdata.zi there will never be cycles anyway, so even if I
> messed the code up, it shouldn't matter unless the application
> provides a custom tzdata.zi with invalid links.
>
> So I guess I'll push it, and backport to gcc-13 soon.


I've pushed the attached, which is the same as the earlier patch
except for adding a new function to the testsuite/std/time/tzdb/1.cc
test.
commit eed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
Author: Jonathan Wakely 
Date:   Thu Apr 18 12:14:41 2024

libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]

Since 2022 the TZif format defined in the zic(8) man page has said that
links can refer to other links, rather than only referring to a zone.
This isn't supported by the C++20 spec, which assumes that the target()
for a chrono::time_zone_link always names a chrono::time_zone, not
another chrono::time_zone_link.

This hasn't been a problem until now, because there are no entries in
the tzdata file that chain links together. However, Debian Sid has
changed the target of the Asia/Chungking link from the Asia/Shanghai
zone to the Asia/Chongqing link, creating a link chain. The libstdc++
code is unable to handle this, so chrono::locate_zone("Asia/Chungking")
will fail with the tzdata.zi file from Debian Sid.

It seems likely that the C++ spec will need a change to allow link
chains, so that the original structure of the IANA database can be fully
represented by chrono::tzdb. The alternative would be for chrono::tzdb
to flatten all chains when loading the data, so that a link's target is
always a zone, but this means throwing away information present in the
tzdata.zi input file.

In anticipation of a change to the spec, this commit adds support for
chained links to libstdc++. When a name is found to be a link, we try to
find its target in the list of zones as before, but now if the target
isn't the name of a zone we don't fail. Instead we look for another link
with that name, and keep doing that until we reach the end of the chain
of links, and then look up the last target as a zone.

This new logic would get stuck in a loop if the tzdata.zi file is buggy
and defines a link chain that contains a cycle, e.g. two links that
refer to each other. To deal with that unlikely case, we use the
tortoise and hare algorithm to detect cycles in link chains, and throw
an exception if we detect a cycle. Cycles in links should never happen,
and it is expected that link chains will be short (if they occur at all)
and so the code is optimized for short chains without cycles. Longer
chains (four or more links) and cycles will do more work, but won't fail
to resolve a chain or get stuck in a loop.

The new test file checks various forms of broken links and cycles.

Also add a new check in the testsuite that every element in the
get_tzdb().zones and get_tzdb().links sequences can be successfully
found using locate_zone.

libstdc++-v3/ChangeLog:

PR libstdc++/114770
* src/c++20/tzdb.cc (do_locate_zone): Support links that have
another link as their target.
* testsuite/std/time/tzdb/1.cc: Check that all zones and links
can be found by locate_zone.
* testsuite/std/time/tzdb/links.cc: New test.

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 639d1c440ba..c7c7cc9deee 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -1599,7 +1599,7 @@ namespace std:

Re: [PATCH] libstdc++: Fix std::ranges::iota is not included in numeric [PR108760]

2024-04-19 Thread Jonathan Wakely
On Thu, 18 Apr 2024 at 22:59, Patrick Palka  wrote:
>
> On Wed, 17 Apr 2024, Michael Levine (BLOOMBERG/ 919 3RD A) wrote:
>
> > This patch fixes GCC Bug 108760: 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> > Before this patch, using std::ranges::iota required including  
> > when it should have been sufficient to only include .
> >
> > When the patch is applied, the following code will compile: 
> > https://godbolt.org/z/33EPeqd1b
> >
> > I added a test case for this change as well.
> >
> > I built my local version of gcc using the following configuration: $ 
> > ../gcc/configure --disable-bootstrap --prefix="$(pwd)/_pfx/" 
> > --enable-languages=c,c++,lto
> >
> > and I tested my changes by running: $ make check-c++ -jN -k
>
> Nice, thanks for the patch!
>
> >
> > I ran this on the following OS:
> >
> > Virtualization: wsl
> > Operating System: Ubuntu 20.04.6 LTS
> > Kernel: Linux 5.15.146.1-microsoft-standard-WSL2
> > Architecture: x86-64
>
> > From bd04070c281572ed7a3b48e3d33543e25b8c8afe Mon Sep 17 00:00:00 2001
> > From: Michael Levine 
> > Date: Fri, 23 Feb 2024 14:13:13 -0500
> > Subject: [PATCH 1/2] Fix the bug
> >
> > Signed-off-by: Michael Levine 
> > ---
> >  libstdc++-v3/include/bits/ranges_algo.h | 52 --
> >  libstdc++-v3/include/bits/stl_numeric.h | 57 -
> >  2 files changed, 56 insertions(+), 53 deletions(-)
> >
> > diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
> > b/libstdc++-v3/include/bits/ranges_algo.h
> > index 62faff173bd..d258be0b93f 100644
> > --- a/libstdc++-v3/include/bits/ranges_algo.h
> > +++ b/libstdc++-v3/include/bits/ranges_algo.h
> > @@ -3521,58 +3521,6 @@ namespace ranges
> >
> >  #endif // __glibcxx_ranges_contains
> >
> > -#if __glibcxx_ranges_iota >= 202202L // C++ >= 23
> > -
> > -  template
> > -struct out_value_result
> > -{
> > -  [[no_unique_address]] _Out out;
> > -  [[no_unique_address]] _Tp value;
> > -
> > -  template
> > - requires convertible_to
> > -   && convertible_to
> > - constexpr
> > - operator out_value_result<_Out2, _Tp2>() const &
> > - { return {out, value}; }
> > -
> > -  template
> > - requires convertible_to<_Out, _Out2>
> > -   && convertible_to<_Tp, _Tp2>
> > - constexpr
> > - operator out_value_result<_Out2, _Tp2>() &&
> > - { return {std::move(out), std::move(value)}; }
> > -};
> > -
> > -  template
> > -using iota_result = out_value_result<_Out, _Tp>;
> > -
> > -  struct __iota_fn
> > -  {
> > -template _Sent, 
> > weakly_incrementable _Tp>
> > -  requires indirectly_writable<_Out, const _Tp&>
> > -  constexpr iota_result<_Out, _Tp>
> > -  operator()(_Out __first, _Sent __last, _Tp __value) const
> > -  {
> > - while (__first != __last)
> > -   {
> > - *__first = static_cast(__value);
> > - ++__first;
> > - ++__value;
> > -   }
> > - return {std::move(__first), std::move(__value)};
> > -  }
> > -
> > -template _Range>
> > -  constexpr iota_result, _Tp>
> > -  operator()(_Range&& __r, _Tp __value) const
> > -  { return (*this)(ranges::begin(__r), ranges::end(__r), 
> > std::move(__value)); }
> > -  };
> > -
> > -  inline constexpr __iota_fn iota{};
> > -
> > -#endif // __glibcxx_ranges_iota
> > -
> >  #if __glibcxx_ranges_find_last >= 202207L // C++ >= 23
> >
> >struct __find_last_fn
> > diff --git a/libstdc++-v3/include/bits/stl_numeric.h 
> > b/libstdc++-v3/include/bits/stl_numeric.h
> > index fe911154ab7..1b06c26dc02 100644
> > --- a/libstdc++-v3/include/bits/stl_numeric.h
> > +++ b/libstdc++-v3/include/bits/stl_numeric.h
> > @@ -59,7 +59,7 @@
> >  #include 
> >  #include 
> >  #include  // For _GLIBCXX_MOVE
> > -
> > +#include  // For _Range as used by std::ranges::iota
> >
> >  namespace std _GLIBCXX_VISIBILITY(default)
> >  {
> > @@ -102,6 +102,61 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >  }
> >  #endif
> >
> > +namespace ranges
> > +{
> > +#if __glibcxx_ranges_iota >= 202202L // C++ >= 23
> > +
> > +  template
> > +struct out_value_result
> > +{
> > +  [[no_unique_address]] _Out out;
> > +  [[no_unique_address]] _Tp value;
> > +
> > +  template
> > + requires convertible_to
> > +   && convertible_to
> > + constexpr
> > + operator out_value_result<_Out2, _Tp2>() const &
> > + { return {out, value}; }
> > +
> > +  template
> > + requires convertible_to<_Out, _Out2>
> > +   && convertible_to<_Tp, _Tp2>
> > + constexpr
> > + operator out_value_result<_Out2, _Tp2>() &&
> > + { return {std::move(out), std::move(value)}; }
> > +};
>
> IIUC out_value_result should continue to be available from , so we
> probably don't want to move it to  (or one of its internal headers).
> Better would be to move it to  I think.
>
> > +
> > +  template
> > +using iota_result = out_value_result<_Out, _Tp>;
> > +
> > +  struct __iota_fn
> > +  {
> > +template _Sent, 
> 

Re: [PATCH] libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]

2024-04-19 Thread Jonathan Wakely
On Fri, 19 Apr 2024 at 07:14, Richard Biener  wrote:
>
> On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely  wrote:
> >
> > This would fix the but, how do people feel about it this close to the
> > gcc-14 release?
>
> Guess we'll have to fix it anyway, so why not now ...

Yeah, I don't think Debian is going to stop using this feature, and it
might get used more widely in future (it's currently part of the
"vanguard" format for tzdata, but might move to "main" one day and
then all distros would have chained links). So it needs to be
backported to gcc-13 too.

> (what could go wrong..)

Well the risk is that my new code doesn't correctly detect cycles, and
so could go into an infinite loop when trying to follow chained links.
The current code on trunk will just fail to find a time_zone and throw
an exception, which is not ideal, but predictable and easily
understood. Attempting to handle chained links adds complexity.

I think my new code is correct so that it won't get stuck in a loop,
and there are tests which should cover it sufficiently. And for
correctly tzdata.zi there will never be cycles anyway, so even if I
messed the code up, it shouldn't matter unless the application
provides a custom tzdata.zi with invalid links.

So I guess I'll push it, and backport to gcc-13 soon.


>
> Richard.
>
> > Tested x86_64-linux.
> >
> > -- >8 --
> >
> > Since 2022 the TZif format defined in the zic(8) man page has said that
> > links can refer to other links, rather than only referring to a zone.
> > This isn't supported by the C++20 spec, which assumes that the target()
> > for a chrono::time_zone_link always names a chrono::time_zone, not
> > another chrono::time_zone_link.
> >
> > This hasn't been a problem until now, because there are no entries in
> > the tzdata file that chain links together. However, Debian Sid has
> > changed the target of the Asia/Chungking link from the Asia/Shanghai
> > zone to the Asia/Chongqing link, creating a link chain. The libstdc++
> > code is unable to handle this, so chrono::locate_zone("Asia/Chungking")
> > will fail with the tzdata.zi file from Debian Sid.
> >
> > It seems likely that the C++ spec will need a change to allow link
> > chains, so that the original structure of the IANA database can be fully
> > represented by chrono::tzdb. The alternative would be for chrono::tzdb
> > to flatten all chains when loading the data, so that a link's target is
> > always a zone, but this means throwing away information present in the
> > tzdata.zi input file.
> >
> > In anticipation of a change to the spec, this commit adds support for
> > chained links to libstdc++. When a name is found to be a link, we try to
> > find its target in the list of zones as before, but now if the target
> > isn't the name of a zone we don't fail. Instead we look for another link
> > with that name, and keep doing that until we reach the end of the chain
> > of links, and then look up the last target as a zone.
> >
> > This new logic would get stuck in a loop if the tzdata.zi file is buggy
> > and defines a link chain that contains a cycle, e.g. two links that
> > refer to each other. To deal with that unlikely case, we use the
> > tortoise and hare algorithm to detect cycles in link chains, and throw
> > an exception if we detect a cycle. Cycles in links should never happen,
> > and it is expected that link chains will be short (if they occur at all)
> > and so the code is optimized for short chains without cycles. Longer
> > chains (four or more links) and cycles will do more work, but won't fail
> > to resolve a chain or get stuck in a loop.
> >
> > libstdc++-v3/ChangeLog:
> >
> > PR libstdc++/114770
> > * src/c++20/tzdb.cc (do_locate_zone): Support links that have
> > another link as their target.
> > * testsuite/std/time/tzdb/links.cc: New test.
> > ---
> >  libstdc++-v3/src/c++20/tzdb.cc|  57 -
> >  libstdc++-v3/testsuite/std/time/tzdb/links.cc | 215 ++
> >  2 files changed, 268 insertions(+), 4 deletions(-)
> >  create mode 100644 libstdc++-v3/testsuite/std/time/tzdb/links.cc
> >
> > diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
> > index 639d1c440ba..c7c7cc9deee 100644
> > --- a/libstdc++-v3/src/c++20/tzdb.cc
> > +++ b/libstdc++-v3/src/c++20/tzdb.cc
> > @@ -1599,7 +1599,7 @@ namespace std::chrono
> >  const time_zone*
> >  do_locate_zone(const vector& zones,
> >const vector& links,
> > -  string_view tz_

Re: [gcc-13 PATCH 2/2] libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

2024-04-18 Thread Jonathan Wakely
On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
>
> This completes the fixes to put all experimental symbols into
> libstdc++exp.a.
>
> On trunk the libstdc++_libbacktrace.a was removed completely and its
> contents aded to libstdc++exp.a instead. We don't want to do that on the
> gcc-13 branch because it will break makefiles using it. We can add the
> contents to libstdc++exp.a and then install a symlink so that
> -lstdc++_libbacktrace still works, but links to libstdc++exp.a instead.

It looks like simply duplicating all the libstdc___libbacktrace_FOO
variables in libbacktrace/Makefile.am does work (see attached patch),
so that we get an installed libstdc++_libbacktrace.a and a
not-installed libstdc++_libbacktraceconvenience.a which gets included
into the installed libstdc++exp.a

So if that's preferable to making the installed
libstdc++_libbacktrace.a a symlink, we can do that.

I still kinda like the symlink approach, because it reduces the size
on disk, and the same approach could be used to get rid of
libstdc++fs.a without breaking makefiles using -lstdc++fs
diff --git a/libstdc++-v3/src/experimental/Makefile.am b/libstdc++-v3/src/experimental/Makefile.am
index 6cdcdf3525d..db6f3321f90 100644
--- a/libstdc++-v3/src/experimental/Makefile.am
+++ b/libstdc++-v3/src/experimental/Makefile.am
@@ -31,7 +31,7 @@ filesystem_lib =
 endif
 
 if ENABLE_BACKTRACE
-backtrace_lib = $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
+backtrace_lib = $(top_builddir)/src/libbacktrace/libstdc++_libbacktraceconvenience.la
 else
 backtrace_lib =
 endif
diff --git a/libstdc++-v3/src/experimental/Makefile.in b/libstdc++-v3/src/experimental/Makefile.in
index 87e52c1c83f..709cc227a1f 100644
--- a/libstdc++-v3/src/experimental/Makefile.in
+++ b/libstdc++-v3/src/experimental/Makefile.in
@@ -149,7 +149,7 @@ am__uninstall_files_from_dir = { \
 am__installdirs = "$(DESTDIR)$(toolexeclibdir)"
 LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
 @ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
-@ENABLE_BACKTRACE_TRUE@am__DEPENDENCIES_2 = $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
+@ENABLE_BACKTRACE_TRUE@am__DEPENDENCIES_2 = $(top_builddir)/src/libbacktrace/libstdc++_libbacktraceconvenience.la
 am__objects_1 = contract.lo
 am_libstdc__exp_la_OBJECTS = $(am__objects_1)
 libstdc__exp_la_OBJECTS = $(am_libstdc__exp_la_OBJECTS)
@@ -452,7 +452,7 @@ toolexeclib_LTLIBRARIES = libstdc++exp.la
 @ENABLE_FILESYSTEM_TS_FALSE@filesystem_lib = 
 @ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
 @ENABLE_BACKTRACE_FALSE@backtrace_lib = 
-@ENABLE_BACKTRACE_TRUE@backtrace_lib = $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
+@ENABLE_BACKTRACE_TRUE@backtrace_lib = $(top_builddir)/src/libbacktrace/libstdc++_libbacktraceconvenience.la
 headers = 
 sources = \
 	contract.cc
diff --git a/libstdc++-v3/src/libbacktrace/Makefile.am b/libstdc++-v3/src/libbacktrace/Makefile.am
index 4a08f11da1e..d45d60c8f69 100644
--- a/libstdc++-v3/src/libbacktrace/Makefile.am
+++ b/libstdc++-v3/src/libbacktrace/Makefile.am
@@ -31,18 +31,21 @@
 
 include $(top_srcdir)/fragment.am
 
-noinst_LTLIBRARIES = libstdc++_libbacktrace.la
+toolexeclib_LTLIBRARIES = libstdc++_libbacktrace.la
+noinst_LTLIBRARIES = libstdc++_libbacktraceconvenience.la
 
 ACLOCAL_AMFLAGS = -I ../.. -I ../../config
 
 # This will be used instead of the common AM_CPPFLAGS from fragment.am
-libstdc___libbacktrace_la_CPPFLAGS = \
+bt_cppflags = \
 	-I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
 	-I ../../../libgcc -I .. -I $(top_srcdir) \
 	-I $(top_srcdir)/../libbacktrace \
 	-I $(top_srcdir)/../libiberty \
 	-include $(top_srcdir)/src/libbacktrace/backtrace-rename.h \
 	$(BACKTRACE_CPPFLAGS)
+libstdc___libbacktrace_la_CPPFLAGS = $(bt_cppflags)
+libstdc___libbacktraceconvenience_la_CPPFLAGS = $(bt_cppflags)
 
 WARN_FLAGS = -W -Wall -Wwrite-strings -Wmissing-format-attribute \
 	 -Wcast-qual
@@ -61,8 +64,9 @@ obj_prefix = std_stacktrace
 
 # Each FILE.c in SOURCES will be compiled to SHORTNAME-FILE.o
 libstdc___libbacktrace_la_SHORTNAME = $(obj_prefix)
+libstdc___libbacktraceconvenience_la_SHORTNAME = $(obj_prefix)
 
-libstdc___libbacktrace_la_SOURCES = \
+sources = \
 	atomic.c \
 	backtrace.c \
 	dwarf.c \
@@ -72,6 +76,8 @@ libstdc___libbacktrace_la_SOURCES = \
 	simple.c \
 	state.c \
 	cp-demangle.c
+libstdc___libbacktrace_la_SOURCES = $(sources)
+libstdc___libbacktraceconvenience_la_SOURCES = $(sources)
 
 FORMAT_FILES = \
 	elf.c \
@@ -86,19 +92,25 @@ ALLOC_FILES = \
 	alloc.c \
 	mmap.c
 
-EXTRA_libstdc___libbacktrace_la_SOURCES = \
+extra_sources = \
 	$(FORMAT_FILES) \
 	$(VIEW_FILES) \
 	$(ALLOC_FILES)
 
+EXTRA_libstdc___libbacktrace_la_SOURCES = $(extra_sources)
+EXTRA_libstdc___libbacktraceconvenience_la_SOURCES = $(extra_sources)
+
 # These three files are chosen by configure and added to the link

[gcc-13 PATCH 0/2] Replace libstdc++_libbacktrace.a with libstdc++exp.a

2024-04-18 Thread Jonathan Wakely
The first patch is a backport from trunk to fix the fact that I messed
up the change to add all symbols from libstdc++fs.a into libstdc++exp.a,
which was backported as r13-8207-g17acf9fbeb10d7. The change builds
libstdc++fs.a twice, once to install it and once as a convenience
library to be included into libstdc++exp.a. That change already works
fine on trunk, so should be fine on gcc-13 too.

The second patch is not a backport but is needed for the branch to
ensure that libstdc++exp.a also provides the symbols for
libstdc++_libbacktrace.a but without removing libstdc++_libbacktrace.a
itself. On trunk I removed it and put all its symbols in libstdc++exp.a,
but on the branch we don't want to stop installing that static lib
halfway through the gcc-13 release series, as it will break makefiles
that are using -lstdc++_libbacktrace to get those symbols.

Because libstdc++-v3/src/libbacktrace/Makefile.am is more complicated
than libstdc++-v3/src/filesystem/Makefile.am and because I don't know
what all the _LIBADD etc. variables do, I'm not sure exactly how to do
the "build it twice, once for installation and once as a convenience
library" thing. So instead what this patch does is change it to a
convenience library (as is done on trunk) but then also create a symlink
with the old installed name, pointing to libstdc++exp.a, so that
using -lstdc++_libbacktrace still works. The symlink is created using
$(LN_S) so for targets that don't support symlinks it's just a copy.

One gotcha is that if you do 'make install' over a pre-existing gcc-13
installation, the new symlinks for libstdc++_libbacktrace.{a,la} won't
be created, because there are already real files with those names. That
won't affect users installing gcc-13.3.0 afresh, it would only affect
people who've been building 13.2.1 from git or from snapshots. Apart
from some errors printed to stderr (and ignored by make) it won't really
matter, because the existing regular files provide the same symbols
anyway.

Does this look reasonable, and done correctly?

Or should I bite the bullet and figure out how to properly adjust
src/libbacktrace/Makefile.am to create an installable library and a
convenience library in parallel? Would I need to copy every
libstdc___libbacktrace_la_FOO variable to create a corresponding
libstdc___libbacktraceconvenience_la_FOO variable?

One advantage of the symlink approach is that we don't increase the
installed footprint of gcc-13 by duplicating all the backtrace symbols
in two static archives. We could even consider making libstdc++fs.a a
symlink to libstdc++exp.a as well, on trunk and gcc-13, to stop
duplicating those symbols.

-- >8 --

Jonathan Wakely (2):
  libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS
symbols
  libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

 libstdc++-v3/src/experimental/Makefile.am |  7 +-
 libstdc++-v3/src/experimental/Makefile.in | 27 ---
 libstdc++-v3/src/filesystem/Makefile.am   |  4 ++
 libstdc++-v3/src/filesystem/Makefile.in   | 37 --
 libstdc++-v3/src/libbacktrace/Makefile.am |  2 +-
 libstdc++-v3/src/libbacktrace/Makefile.in | 86 ---
 6 files changed, 73 insertions(+), 90 deletions(-)

-- 
2.44.0



[gcc-13 PATCH 2/2] libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

2024-04-18 Thread Jonathan Wakely
This completes the fixes to put all experimental symbols into
libstdc++exp.a.

On trunk the libstdc++_libbacktrace.a was removed completely and its
contents aded to libstdc++exp.a instead. We don't want to do that on the
gcc-13 branch because it will break makefiles using it. We can add the
contents to libstdc++exp.a and then install a symlink so that
-lstdc++_libbacktrace still works, but links to libstdc++exp.a instead.

libstdc++-v3/ChangeLog:

* src/experimental/Makefile.am (install-exec-local): New target.
* src/experimental/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.am: Build libstdc++_libbacktrace as
noinst_LTLIBRARIES so it's only a convenience library.
* src/libbacktrace/Makefile.in: Regenerate.
---
 libstdc++-v3/src/experimental/Makefile.am |  5 ++
 libstdc++-v3/src/experimental/Makefile.in | 23 +++---
 libstdc++-v3/src/libbacktrace/Makefile.am |  2 +-
 libstdc++-v3/src/libbacktrace/Makefile.in | 86 ---
 4 files changed, 35 insertions(+), 81 deletions(-)

diff --git a/libstdc++-v3/src/experimental/Makefile.am 
b/libstdc++-v3/src/experimental/Makefile.am
index c5a38d882c2..6cdcdf3525d 100644
--- a/libstdc++-v3/src/experimental/Makefile.am
+++ b/libstdc++-v3/src/experimental/Makefile.am
@@ -66,6 +66,11 @@ AM_CXXFLAGS = \
 AM_MAKEFLAGS = \
"gxx_include_dir=$(gxx_include_dir)"
 
+install-exec-local:
+   -cd '$(DESTDIR)$(toolexeclibdir)' && \
+   $(LN_S) libstdc++exp.la libstdc++_libbacktrace.la && \
+   $(LN_S) libstdc++exp.a libstdc++_libbacktrace.a
+
 # Libtool notes
 
 # 1) In general, libtool expects an argument such as `--tag=CXX' when
diff --git a/libstdc++-v3/src/experimental/Makefile.in 
b/libstdc++-v3/src/experimental/Makefile.in
index c16083a7fc8..87e52c1c83f 100644
--- a/libstdc++-v3/src/experimental/Makefile.in
+++ b/libstdc++-v3/src/experimental/Makefile.in
@@ -740,7 +740,7 @@ install-dvi: install-dvi-am
 
 install-dvi-am:
 
-install-exec-am: install-toolexeclibLTLIBRARIES
+install-exec-am: install-exec-local install-toolexeclibLTLIBRARIES
 
 install-html: install-html-am
 
@@ -789,18 +789,23 @@ uninstall-am: uninstall-toolexeclibLTLIBRARIES
distclean-libtool distclean-tags dvi dvi-am html html-am info \
info-am install install-am install-data install-data-am \
install-dvi install-dvi-am install-exec install-exec-am \
-   install-html install-html-am install-info install-info-am \
-   install-man install-pdf install-pdf-am install-ps \
-   install-ps-am install-strip install-toolexeclibLTLIBRARIES \
-   installcheck installcheck-am installdirs maintainer-clean \
-   maintainer-clean-generic mostlyclean mostlyclean-compile \
-   mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
-   tags tags-am uninstall uninstall-am \
-   uninstall-toolexeclibLTLIBRARIES
+   install-exec-local install-html install-html-am install-info \
+   install-info-am install-man install-pdf install-pdf-am \
+   install-ps install-ps-am install-strip \
+   install-toolexeclibLTLIBRARIES installcheck installcheck-am \
+   installdirs maintainer-clean maintainer-clean-generic \
+   mostlyclean mostlyclean-compile mostlyclean-generic \
+   mostlyclean-libtool pdf pdf-am ps ps-am tags tags-am uninstall \
+   uninstall-am uninstall-toolexeclibLTLIBRARIES
 
 .PRECIOUS: Makefile
 
 
+install-exec-local:
+   -cd '$(DESTDIR)$(toolexeclibdir)' && \
+   $(LN_S) libstdc++exp.la libstdc++_libbacktrace.la && \
+   $(LN_S) libstdc++exp.a libstdc++_libbacktrace.a
+
 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.
 .NOEXPORT:
diff --git a/libstdc++-v3/src/libbacktrace/Makefile.am 
b/libstdc++-v3/src/libbacktrace/Makefile.am
index 3992f3ab9c5..4a08f11da1e 100644
--- a/libstdc++-v3/src/libbacktrace/Makefile.am
+++ b/libstdc++-v3/src/libbacktrace/Makefile.am
@@ -31,7 +31,7 @@
 
 include $(top_srcdir)/fragment.am
 
-toolexeclib_LTLIBRARIES = libstdc++_libbacktrace.la
+noinst_LTLIBRARIES = libstdc++_libbacktrace.la
 
 ACLOCAL_AMFLAGS = -I ../.. -I ../../config
 
diff --git a/libstdc++-v3/src/libbacktrace/Makefile.in 
b/libstdc++-v3/src/libbacktrace/Makefile.in
index f5f19149ae6..6b898f65b06 100644
--- a/libstdc++-v3/src/libbacktrace/Makefile.in
+++ b/libstdc++-v3/src/libbacktrace/Makefile.in
@@ -150,35 +150,7 @@ DIST_COMMON = $(srcdir)/Makefile.am
 CONFIG_HEADER = $(top_builddir)/config.h
 CONFIG_CLEAN_FILES = backtrace-supported.h
 CONFIG_CLEAN_VPATH_FILES =
-am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
-am__vpath_adj = case $$p in \
-$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
-*) f=$$p;; \
-  esac;
-am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
-am__install_max = 40
-am__nobase_strip_setup = \
-  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/&/g'`
-am__nobase_strip = \
-  for p in $$list; 

[gcc-13 PATCH 1/2] libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbols

2024-04-18 Thread Jonathan Wakely
In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
but that wasn't true. Only the symbols from the latter were added to
libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
libtool won't combine static libs that are going to be installed
separately. Because libstdc++fs.a is still installed, libtool decides it
shouldn't be included in libstdc++exp.a.

The solution is similar to what we already do for libsupc++.a: build two
static libs, libstdc++fs.a and libstdc++fsconvenience.a, where the
former is installed and the latter isn't. If we then tell libtool to
include the latter in libstdc++exp.a it will do as it's told.

libstdc++-v3/ChangeLog:

* src/experimental/Makefile.am: Use libstdc++fsconvenience.a
instead of libstdc++fs.a.
* src/experimental/Makefile.in: Regenerate.
* src/filesystem/Makefile.am: Build libstdc++fsconvenience.a as
well.
* src/filesystem/Makefile.in: Regenerate.

(cherry picked from commit abf40d2953639534af3428424f467adf3cb52177)
---
 libstdc++-v3/src/experimental/Makefile.am |  2 +-
 libstdc++-v3/src/experimental/Makefile.in |  4 +--
 libstdc++-v3/src/filesystem/Makefile.am   |  4 +++
 libstdc++-v3/src/filesystem/Makefile.in   | 37 +++
 4 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/src/experimental/Makefile.am 
b/libstdc++-v3/src/experimental/Makefile.am
index 1c7cea7e846..c5a38d882c2 100644
--- a/libstdc++-v3/src/experimental/Makefile.am
+++ b/libstdc++-v3/src/experimental/Makefile.am
@@ -25,7 +25,7 @@ include $(top_srcdir)/fragment.am
 toolexeclib_LTLIBRARIES = libstdc++exp.la
 
 if ENABLE_FILESYSTEM_TS
-filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fs.la
+filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
 else
 filesystem_lib =
 endif
diff --git a/libstdc++-v3/src/experimental/Makefile.in 
b/libstdc++-v3/src/experimental/Makefile.in
index 6f6b742c1cf..c16083a7fc8 100644
--- a/libstdc++-v3/src/experimental/Makefile.in
+++ b/libstdc++-v3/src/experimental/Makefile.in
@@ -148,7 +148,7 @@ am__uninstall_files_from_dir = { \
   }
 am__installdirs = "$(DESTDIR)$(toolexeclibdir)"
 LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
-@ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = 
$(top_builddir)/src/filesystem/libstdc++fs.la
+@ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = 
$(top_builddir)/src/filesystem/libstdc++fsconvenience.la
 @ENABLE_BACKTRACE_TRUE@am__DEPENDENCIES_2 = 
$(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
 am__objects_1 = contract.lo
 am_libstdc__exp_la_OBJECTS = $(am__objects_1)
@@ -450,7 +450,7 @@ WARN_CXXFLAGS = \
 AM_CPPFLAGS = $(GLIBCXX_INCLUDES) $(CPPFLAGS)
 toolexeclib_LTLIBRARIES = libstdc++exp.la
 @ENABLE_FILESYSTEM_TS_FALSE@filesystem_lib = 
-@ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = 
$(top_builddir)/src/filesystem/libstdc++fs.la
+@ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = 
$(top_builddir)/src/filesystem/libstdc++fsconvenience.la
 @ENABLE_BACKTRACE_FALSE@backtrace_lib = 
 @ENABLE_BACKTRACE_TRUE@backtrace_lib = 
$(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
 headers = 
diff --git a/libstdc++-v3/src/filesystem/Makefile.am 
b/libstdc++-v3/src/filesystem/Makefile.am
index d2e1fde3f13..55f309b5c15 100644
--- a/libstdc++-v3/src/filesystem/Makefile.am
+++ b/libstdc++-v3/src/filesystem/Makefile.am
@@ -22,7 +22,10 @@
 
 include $(top_srcdir)/fragment.am
 
+# Separate libstdc++fs.a to be installed.
 toolexeclib_LTLIBRARIES = libstdc++fs.la
+# Duplicate lib that is to be part of libstdc++exp.a
+noinst_LTLIBRARIES = libstdc++fsconvenience.la
 
 headers =
 
@@ -44,6 +47,7 @@ sources = \
 # vpath % $(top_srcdir)/src/filesystem
 
 libstdc__fs_la_SOURCES = $(sources)
+libstdc__fsconvenience_la_SOURCES = $(sources)
 
 # AM_CXXFLAGS needs to be in each subdirectory so that it can be
 # modified in a per-library or per-sub-library way.  Need to manually
diff --git a/libstdc++-v3/src/filesystem/Makefile.in 
b/libstdc++-v3/src/filesystem/Makefile.in
index 852390ec1a9..76ba905087b 100644
--- a/libstdc++-v3/src/filesystem/Makefile.in
+++ b/libstdc++-v3/src/filesystem/Makefile.in
@@ -147,7 +147,7 @@ am__uninstall_files_from_dir = { \
  $(am__cd) "$$dir" && rm -f $$files; }; \
   }
 am__installdirs = "$(DESTDIR)$(toolexeclibdir)"
-LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
+LTLIBRARIES = $(noinst_LTLIBRARIES) $(toolexeclib_LTLIBRARIES)
 libstdc__fs_la_LIBADD =
 @ENABLE_DUAL_ABI_TRUE@am__objects_1 = cow-dir.lo cow-ops.lo \
 @ENABLE_DUAL_ABI_TRUE@ cow-path.lo
@@ -158,6 +158,10 @@ AM_V_lt = $(am__v_lt_@AM_V@)
 am__v_lt_ = $(am__v_lt_@AM_DEFAULT_V@)
 am__v_lt_0 = --silent
 am__v_lt_1 = 
+libstdc__fsconvenience_la_LIBADD =
+am_libstdc__fsconvenience_la_OBJECTS = $(am__objects_2)
+libstdc__fsconvenience_la_OBJECTS =  \
+   $(am_libstdc__fsconvenience_la_OBJECTS)
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
 

Re: [PATCH] libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]

2024-04-18 Thread Jonathan Wakely
On Thu, 18 Apr 2024 at 17:33, Jonathan Wakely wrote:
>
> This would fix the but,

*fix the bug

> how do people feel about it this close to the
> gcc-14 release?
>
> Tested x86_64-linux.



[PATCH] libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]

2024-04-18 Thread Jonathan Wakely
This would fix the but, how do people feel about it this close to the
gcc-14 release?

Tested x86_64-linux.

-- >8 --

Since 2022 the TZif format defined in the zic(8) man page has said that
links can refer to other links, rather than only referring to a zone.
This isn't supported by the C++20 spec, which assumes that the target()
for a chrono::time_zone_link always names a chrono::time_zone, not
another chrono::time_zone_link.

This hasn't been a problem until now, because there are no entries in
the tzdata file that chain links together. However, Debian Sid has
changed the target of the Asia/Chungking link from the Asia/Shanghai
zone to the Asia/Chongqing link, creating a link chain. The libstdc++
code is unable to handle this, so chrono::locate_zone("Asia/Chungking")
will fail with the tzdata.zi file from Debian Sid.

It seems likely that the C++ spec will need a change to allow link
chains, so that the original structure of the IANA database can be fully
represented by chrono::tzdb. The alternative would be for chrono::tzdb
to flatten all chains when loading the data, so that a link's target is
always a zone, but this means throwing away information present in the
tzdata.zi input file.

In anticipation of a change to the spec, this commit adds support for
chained links to libstdc++. When a name is found to be a link, we try to
find its target in the list of zones as before, but now if the target
isn't the name of a zone we don't fail. Instead we look for another link
with that name, and keep doing that until we reach the end of the chain
of links, and then look up the last target as a zone.

This new logic would get stuck in a loop if the tzdata.zi file is buggy
and defines a link chain that contains a cycle, e.g. two links that
refer to each other. To deal with that unlikely case, we use the
tortoise and hare algorithm to detect cycles in link chains, and throw
an exception if we detect a cycle. Cycles in links should never happen,
and it is expected that link chains will be short (if they occur at all)
and so the code is optimized for short chains without cycles. Longer
chains (four or more links) and cycles will do more work, but won't fail
to resolve a chain or get stuck in a loop.

libstdc++-v3/ChangeLog:

PR libstdc++/114770
* src/c++20/tzdb.cc (do_locate_zone): Support links that have
another link as their target.
* testsuite/std/time/tzdb/links.cc: New test.
---
 libstdc++-v3/src/c++20/tzdb.cc|  57 -
 libstdc++-v3/testsuite/std/time/tzdb/links.cc | 215 ++
 2 files changed, 268 insertions(+), 4 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/time/tzdb/links.cc

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 639d1c440ba..c7c7cc9deee 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -1599,7 +1599,7 @@ namespace std::chrono
 const time_zone*
 do_locate_zone(const vector& zones,
   const vector& links,
-  string_view tz_name) noexcept
+  string_view tz_name)
 {
   // Lambda mangling changed between -fabi-version=2 and -fabi-version=18
   auto search = [](const Vec& v, string_view name) {
@@ -1610,13 +1610,62 @@ namespace std::chrono
return ptr;
   };
 
+  // Search zones first.
   if (auto tz = search(zones, tz_name))
return tz;
 
+  // Search links second.
   if (auto tz_l = search(links, tz_name))
-   return search(zones, tz_l->target());
+   {
+ // Handle the common case of a link that has a zone as the target.
+ if (auto tz = search(zones, tz_l->target())) [[likely]]
+   return tz;
 
-  return nullptr;
+ // Either tz_l->target() doesn't exist, or we have a chain of links.
+ // Use Floyd's cycle-finding algorithm to avoid infinite loops,
+ // at the cost of extra lookups. In the common case we expect a
+ // chain of links to be short so the loop won't run many times.
+ // In particular, the duplicate lookups to move the tortoise
+ // never happen unless the chain has four or more links.
+ // When a chain contains a cycle we do multiple duplicate lookups,
+ // but that case should never happen with correct tzdata.zi,
+ // so there's no need to optimize cycle detection.
+
+ const time_zone_link* tortoise = tz_l;
+ const time_zone_link* hare = search(links, tz_l->target());
+ while (hare)
+   {
+ // Chains should be short, so first check if it ends here:
+ if (auto tz = search(zones, hare->target())) [[likely]]
+   return tz;
+
+ // Otherwise follow the chain:
+ hare = search(links, hare->target());
+ if (!hare)
+   break;
+
+ // Again, first check if the chain ends at a zone here:
+ if (auto tz = 

[committed] libstdc++: Implement "Printing blank lines with println" for C++23

2024-04-17 Thread Jonathan Wakely
Tested x86_64-linux and x86_64-freebsd. Pushed to trunk.

-- >8 --

This was recently approved for C++26 at the Tokyo meeting. As suggested
by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode
(when std::print and std::prinln were first added) rather than as a new
C++26 feature. Both MSVC and libc++ have agreed to do this too.

libstdc++-v3/ChangeLog:

* include/std/ostream (println(ostream&)): Define new overload.
* include/std/print (println(FILE*), println()): Likewise.
* testsuite/27_io/basic_ostream/print/2.cc: New test.
* testsuite/27_io/print/1.cc: Remove unused header.
* testsuite/27_io/print/3.cc: New test.
---
 libstdc++-v3/include/std/ostream  | 12 +
 libstdc++-v3/include/std/print| 14 +
 .../testsuite/27_io/basic_ostream/print/2.cc  | 47 
 libstdc++-v3/testsuite/27_io/print/1.cc   |  1 -
 libstdc++-v3/testsuite/27_io/print/3.cc   | 53 +++
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/print/3.cc

diff --git a/libstdc++-v3/include/std/ostream b/libstdc++-v3/include/std/ostream
index a136399ad0b..8a21758d0a3 100644
--- a/libstdc++-v3/include/std/ostream
+++ b/libstdc++-v3/include/std/ostream
@@ -995,6 +995,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   std::print(__os, "{}\n",
 std::format(__fmt, std::forward<_Args>(__args)...));
 }
+
+  // Defined for C++26, supported as an extension to C++23.
+  inline void println(ostream& __os)
+  {
+#if defined(_WIN32) && !defined(__CYGWIN__)
+if constexpr (__unicode::__literal_encoding_is_utf8())
+  std::vprint_unicode(__os, "\n", std::make_format_args());
+else
+#endif
+  __os.put('\n');
+  }
+
 #endif // __cpp_lib_print
 
 #endif // C++11
diff --git a/libstdc++-v3/include/std/print b/libstdc++-v3/include/std/print
index d44033469de..0c259d04de3 100644
--- a/libstdc++-v3/include/std/print
+++ b/libstdc++-v3/include/std/print
@@ -136,6 +136,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   vprint_nonunicode(string_view __fmt, format_args __args)
   { std::vprint_nonunicode(stdout, __fmt, __args); }
 
+  // Defined for C++26, supported as an extension to C++23.
+  inline void println(FILE* __stream)
+  {
+#if defined(_WIN32) && !defined(__CYGWIN__)
+if constexpr (__unicode::__literal_encoding_is_utf8())
+  std::vprint_unicode(__stream, "\n", std::make_format_args());
+else
+#endif
+  if (std::putc('\n', __stream) == EOF)
+   __throw_system_error(EIO);
+  }
+
+  inline void println() { std::println(stdout); }
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 #endif // __cpp_lib_print
diff --git a/libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc 
b/libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc
new file mode 100644
index 000..5d1e3efdbf7
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc
@@ -0,0 +1,47 @@
+// { dg-additional-options "-lstdc++exp" { target { *-*-mingw* } } }
+// { dg-do run { target c++23 } }
+// { dg-require-fileio "" }
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void
+test_println_blank_ostream()
+{
+  char buf[4];
+  std::spanstream os(buf);
+  std::println(os);
+  std::string_view txt(os.span());
+  VERIFY( txt == "\n" );
+}
+
+void
+test_errors()
+{
+  // Failure to generate output is reported by setting badbit.
+  std::stringstream in(std::ios::in);
+  std::println(in); // No exception here.
+  VERIFY(in.bad());
+#ifdef __cpp_exceptions
+  in.clear();
+  in.exceptions(std::ios::badbit);
+  try
+  {
+std::println(in); // Should throw now.
+VERIFY(false);
+  }
+  catch (const std::ios::failure&)
+  {
+  }
+#endif
+}
+
+int main()
+{
+  test_println_blank_ostream();
+  test_errors();
+}
diff --git a/libstdc++-v3/testsuite/27_io/print/1.cc 
b/libstdc++-v3/testsuite/27_io/print/1.cc
index d570f7938be..f6585d9880a 100644
--- a/libstdc++-v3/testsuite/27_io/print/1.cc
+++ b/libstdc++-v3/testsuite/27_io/print/1.cc
@@ -4,7 +4,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/libstdc++-v3/testsuite/27_io/print/3.cc 
b/libstdc++-v3/testsuite/27_io/print/3.cc
new file mode 100644
index 000..ffcf7337ce5
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/print/3.cc
@@ -0,0 +1,53 @@
+// { dg-additional-options "-lstdc++exp" { target { *-*-mingw* } } }
+// { dg-do run { target c++23 } }
+// { dg-require-fileio "" }
+
+#include 
+#include 
+#include 
+#include 
+
+void
+test_println_blank()
+{
+  std::print("1");
+  std::println();
+  std::println("2");
+  // { dg-output "1\n2" }
+}
+
+void
+test_println_blank_file()
+{
+  __gnu_test::scoped_file f;
+  FILE* strm = std::fopen(f.path.string().c_str(), "w");
+  VERIFY( strm );
+  std::println(strm);
+  std::fclose(strm);
+
+  std::ifstream in(f.path);
+  std::string 

Re: [PATCH] libstdc++: Add include guard to simd-internal header

2024-04-17 Thread Jonathan Wakely
On Wed, 17 Apr 2024 at 09:17, Matthias Kretz  wrote:
>
> This never showed up as an issue because it's an internal header and
> implicitly guarded by bits/simd.h.
>
> OK for trunk? Any reason to backport?

OK for trunk, I think it's worth backporting too.


>
> - 8< --
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/numeric_traits.h: Add include guard.
> ---
>  libstdc++-v3/include/experimental/bits/numeric_traits.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libstdc++-v3/include/experimental/bits/numeric_traits.h b/
> libstdc++-v3/include/experimental/bits/numeric_traits.h
> index b195de7c3db..8717f684d96 100644
> --- a/libstdc++-v3/include/experimental/bits/numeric_traits.h
> +++ b/libstdc++-v3/include/experimental/bits/numeric_traits.h
> @@ -22,6 +22,9 @@
>  // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  // .
>
> +#ifndef _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
> +#define _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
> +
>  #include 
>
>  namespace std {
> @@ -565,3 +568,4 @@ struct __has_iec559_behavior<__signaling_NaN, long
> double>
>  #endif // __FINITE_MATH_ONLY__
>
>  } // namespace std
> +#endif  // _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──
>


Re: [PATCH] libstdc++: Avoid ill-formed types on ARM

2024-04-17 Thread Jonathan Wakely
On Wed, 17 Apr 2024 at 08:58, Matthias Kretz  wrote:
>
> Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.
>
> OK for trunk and backports?

OK, thanks.


>
> - 8< --
>
> This resolves failing tests in check-simd.
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/114750
> * include/experimental/bits/simd_builtin.h
> (_SimdImplBuiltin::_S_load, _S_store): Fall back to copying
> scalars if the memory type cannot be vectorized for the target.
> ---
>  libstdc++-v3/include/experimental/bits/simd_builtin.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──


[committed] libstdc++: Fix "extact" typos in comments

2024-04-16 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* config/locale/dragonfly/numeric_members.cc: Fix typos in
comments.
* config/locale/gnu/numeric_members.cc: Likewise.
---
 libstdc++-v3/config/locale/dragonfly/numeric_members.cc | 4 ++--
 libstdc++-v3/config/locale/gnu/numeric_members.cc   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/config/locale/dragonfly/numeric_members.cc 
b/libstdc++-v3/config/locale/dragonfly/numeric_members.cc
index 4e8364f6f44..dc71ef4ed70 100644
--- a/libstdc++-v3/config/locale/dragonfly/numeric_members.cc
+++ b/libstdc++-v3/config/locale/dragonfly/numeric_members.cc
@@ -115,7 +115,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
 
-  // NB: There is no way to extact this info from posix locales.
+  // NB: There is no way to extract this info from posix locales.
   // _M_truename = __nl_langinfo_l(YESSTR, __cloc);
   _M_data->_M_truename = "true";
   _M_data->_M_truename_size = 4;
@@ -213,7 +213,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
 
-  // NB: There is no way to extact this info from posix locales.
+  // NB: There is no way to extract this info from posix locales.
   // _M_truename = __nl_langinfo_l(YESSTR, __cloc);
   _M_data->_M_truename = L"true";
   _M_data->_M_truename_size = 4;
diff --git a/libstdc++-v3/config/locale/gnu/numeric_members.cc 
b/libstdc++-v3/config/locale/gnu/numeric_members.cc
index 3d1a88ae832..f061065922f 100644
--- a/libstdc++-v3/config/locale/gnu/numeric_members.cc
+++ b/libstdc++-v3/config/locale/gnu/numeric_members.cc
@@ -159,7 +159,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
 
-  // NB: There is no way to extact this info from posix locales.
+  // NB: There is no way to extract this info from posix locales.
   // _M_truename = __nl_langinfo_l(YESSTR, __cloc);
   _M_data->_M_truename = "true";
   _M_data->_M_truename_size = 4;
@@ -251,7 +251,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
 
-  // NB: There is no way to extact this info from posix locales.
+  // NB: There is no way to extract this info from posix locales.
   // _M_truename = __nl_langinfo_l(YESSTR, __cloc);
   _M_data->_M_truename = L"true";
   _M_data->_M_truename_size = 4;
-- 
2.44.0



Re: [PATCH] [libstdc++] introduce --disable-compat-libstdcxx-abi

2024-04-16 Thread Jonathan Wakely
On Tue, 16 Apr 2024 at 04:37, Alexandre Oliva  wrote:
>
>
> A number of libstdc++ tests that implicitly instantiate
> __to_chars_i and also link floating_to_chars.o in
> fail on vxworks kernel mode.  The platform doesn't support undefweak
> symbols (the kernel module loader fails to load modules containing
> them), and because creating such modules doesn't involve final
> linking, only -r linking.  The vague-linkage weak defs with abi-v2
> mangling that get discarded from floating_to_chars.o because the same
> comdat section is present in the main executable.  But since the
> alternate mangling is not defined in the main executable, the weak
> definition decays to a weak undefined symbol in the partially-linked
> kernel module, and then the kernel module loader barfs.
>
> Since our vxworks toolchains have little use for the compat ABI
> symbols, I thought we could work around this problem by getting rid of
> them.  Absent a configure option to control that, I added one.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>
> PS: for an alternate path to avoid this problem, see also
> https://sourceware.org/pipermail/binutils/2024-April/133602.html
> https://sourceware.org/pipermail/binutils/2024-April/133410.html
>
>
> for  libstdc++-v3/ChangeLog
>
> * acinclude.m4 (GLIBCXX_EXPORT_FLAGS): Split -Wabi=2...
> (GLIBCXX_ENABLE_WABI): ... here.  Control it with newly added
> --disable-compat-libstdcxx-abi.
> * configure: Rebuilt.
> * doc/html/manual/configure.html: Document it.
> ---
>  libstdc++-v3/acinclude.m4   |   26 ++
>  libstdc++-v3/configure  |   49 
> ++-
>  libstdc++-v3/doc/html/manual/configure.html |2 +
>  3 files changed, 67 insertions(+), 10 deletions(-)
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 51a08bcc8b1d0..4ef5d5e98c2be 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -707,10 +707,34 @@ AC_DEFUN([GLIBCXX_EXPORT_FLAGS], [
># OPTIMIZE_CXXFLAGS = -O3 -fstrict-aliasing -fvtable-gc
>AC_SUBST(OPTIMIZE_CXXFLAGS)
>
> -  WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2"
> +  WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual"
>AC_SUBST(WARN_FLAGS)
> +
> +  GLIBCXX_ENABLE_WABI
>  ])
>
> +dnl
> +dnl Enable -Wabi=2 if not overridden by --disable-compat-libstdcxx-abi.
> +dnl
> +AC_DEFUN([GLIBCXX_ENABLE_WABI], [
> +  # Default.
> +  WARN_FLAGS_WABI=\ -Wabi=2
> +  AC_MSG_CHECKING([for --disable-compat-libstdcxx-abi])
> +  AC_ARG_ENABLE([compat-libstdcxx-abi],

We have the GLIBCXX_ENABLE macro to simplify creating new --enable options.

> +AC_HELP_STRING([--disable-compat-libstdcxx-abi],
> +  [Disable backward-compatibility ABI symbols)]),

There's a stray ')' here.

> +[case "$enableval" in
> +  yes) AC_MSG_RESULT(enabled$WARN_FLAGS_WABI) ;;
> +  no)  WARN_FLAGS_WABI=
> +  AC_MSG_RESULT(disabled) ;;
> +  *)   AC_MSG_RESULT(unsupported)
> +  AC_MSG_ERROR([Unsupported argument to enable/disable compat 
> libstdc++ abi]);;
> + esac], [
> +  AC_MSG_RESULT(defaulting to enabled$WARN_FLAGS_WABI)
> + ])
> +
> +  WARN_FLAGS="$WARN_FLAGS$WARN_FLAGS_WABI"
> +])
>
>  dnl
>  dnl All installation directory information is determined here.

[...]

> diff --git a/libstdc++-v3/doc/html/manual/configure.html 
> b/libstdc++-v3/doc/html/manual/configure.html
> index 346b5d345cd1b..8636b2360d9f0 100644
> --- a/libstdc++-v3/doc/html/manual/configure.html
> +++ b/libstdc++-v3/doc/html/manual/configure.html
> @@ -108,6 +108,8 @@
> then the [time.clock] implementation will use a system call to access
> the realtime and monotonic clocks, which is significantly slower than
> the C library's clock_gettime function.
> + class="code">--disable-compat-libstdcxx-abiDisables
> +backward-compatibility ABI symbols.
>   class="code">--enable-libstdcxx-debugBuild separate 
> debug libraries in addition to what is normally built.
> By default, the debug libraries are compiled with
>  CXXFLAGS='-g3 -O0 -fno-inline'

This should be in doc/xml/manual/configure.xml too, which is used to
generate the HTML using docbook. Otherwise this change will be lost
next time the docs are regenerated.

The description here in the docs (and the name of the configure
option) seem much too vague. Libstdc++ has dozens, probably hundreds,
of "backward-compatibility ABI symbols", and this only affects touches
a tiny handful of them. Just the aliases created automatically by the
compiler for mangling changes, right? From the name of the configure
option and the doc entry, I'd expect it to also affect e.g.
src/c++11/compatibility-*.cc and maybe to have some interaction with
--disable-libstdcxx-dual-abi.

The change seems fine in principle, but needs a better name and 

Re: [PATCH] [libstdc++] [testsuite] disable SRA for compare_exchange_padding

2024-04-16 Thread Jonathan Wakely
On Tue, 16 Apr 2024 at 04:49, Alexandre Oliva  wrote:
>
>
> On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
> padding bits in the tests are not what we might expect from full-word
> struct copies.

Aha, I was wondering why this was failing on ARM!


> I tried adding a function to perform bitwise copying, but even taking
> the as.load() argument by const&, we'd still construct a temporary
> with SRAed field-wise copying.  Unable to find another way to ensure
> we wouldn't get a temporary, I went for disabling SRA.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?

Yes, thanks.

>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/29_atomics/atomic/compare_exchange_padding.cc:
> Disable SRA.
> ---
>  .../29_atomics/atomic/compare_exchange_padding.cc  |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git 
> a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> index 2f18d426e7f7e..a6081968ca869 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> @@ -1,6 +1,7 @@
>  // { dg-do run { target c++20 } }
>  // { dg-require-atomic-cmpxchg-word "" }
>  // { dg-add-options libatomic }
> +// { dg-additional-options "-fno-tree-sra" }
>
>  #include 
>  #include 
> @@ -26,10 +27,10 @@ main ()
>s.s = 42;
>
>std::atomic as{ s };
> -  auto ts = as.load();
> +  auto ts = as.load(); // SRA might prevent copying of padding bits here.
>VERIFY( !compare_struct(s, ts) ); // padding cleared on construction
>as.exchange(s);
> -  auto es = as.load();
> +  auto es = as.load(); // SRA might prevent copying of padding bits here.
>VERIFY( compare_struct(ts, es) ); // padding cleared on exchange
>
>S n;
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive


Re: [PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t

2024-04-16 Thread Jonathan Wakely
On Tue, 16 Apr 2024, 04:19 Alexandre Oliva,  wrote:

>
> Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
> adjusted about a year ago to skip long double on some targets, because
> the fastfloat library was limited to 64-bit doubles.
>
> The same problem comes up in similar float128_t tests on
> aarch64-vxworks.  This patch adjusts them similarly.
>
> Unlike the earlier tests, that got similar treatment for
> x86_64-vxworks, these haven't failed there.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>

OK, thanks



>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/20_util/from_chars/8.cc: Skip float128_t testing
> on aarch64-vxworks.
> * testsuite/20_util/to_chars/float128-c++23.cc: Xfail run on
> aarch64-vxworks.
> ---
>  libstdc++-v3/testsuite/20_util/from_chars/8.cc |3 ++-
>  .../testsuite/20_util/to_chars/float128_c++23.cc   |1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> index ee60d88c332db..a6343422c5a91 100644
> --- a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> +++ b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++23 } }
>  // { dg-add-options ieee }
> +// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target
> aarch64-*-vxworks* } }
>
>  #include 
>  #include 
> @@ -343,7 +344,7 @@ test06()
>  #if defined(__STDCPP_FLOAT64_T__) &&
> defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
>test_max_mantissa();
>  #endif
> -#if defined(__GLIBCXX_TYPE_INT_N_0) \
> +#if defined(__GLIBCXX_TYPE_INT_N_0) && !defined SKIP_LONG_DOUBLE \
>  && defined(__STDCPP_FLOAT128_T__) &&
> defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
>test_max_mantissa();
>  #endif
> diff --git a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> index 547632817b4bb..ca00761ee7c98 100644
> --- a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> +++ b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> @@ -19,6 +19,7 @@
>  // { dg-require-effective-target ieee_floats }
>  // { dg-require-effective-target size32plus }
>  // { dg-add-options ieee }
> +// { dg-xfail-run-if "from_chars limited to double-precision" {
> aarch64-*-vxworks* } }
>
>  #include 
>  #include 
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>


Re: [PATCH] [libstdc++] define zoneinfo_dir_override on vxworks

2024-04-16 Thread Jonathan Wakely
On Tue, 16 Apr 2024, 04:17 Alexandre Oliva,  wrote:

>
> VxWorks fails to load kernel-mode modules with weak undefined symbols.
> In RTP mode modules, that undergo final linking, weak undefined
> symbols are not a problem.
>
> This patch adds kernel-mode VxWorks multilibs to the set of targets
> that don't support weak undefined symbols without special flags, in
> which tzdb's zoneinfo_dir_override is given a weak definition.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>

OK, thanks.



>
> for  libstdc++-v3/ChangeLog
>
> * src/c++20/tzdb.cc (__gnu_cxx::zoneinfo_dir_override): Define
> on VxWorks non-RTP.
> ---
>  libstdc++-v3/src/c++20/tzdb.cc |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++20/tzdb.cc
> b/libstdc++-v3/src/c++20/tzdb.cc
> index 890a4c53e2d44..639d1c440ba16 100644
> --- a/libstdc++-v3/src/c++20/tzdb.cc
> +++ b/libstdc++-v3/src/c++20/tzdb.cc
> @@ -70,8 +70,9 @@ namespace __gnu_cxx
>  #else
>[[gnu::weak]] const char* zoneinfo_dir_override();
>
> -#if defined(__APPLE__) || defined(__hpux__)
> -  // Need a weak definition for Mach-O.
> +#if defined(__APPLE__) || defined(__hpux__) \
> +  || (defined(__VXWORKS__) && !defined(__RTP__))
> +  // Need a weak definition for Mach-O et al.
>[[gnu::weak]] const char* zoneinfo_dir_override()
>{
>  #ifdef _GLIBCXX_ZONEINFO_DIR
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>


Re: [PATCH v2] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-15 Thread Jonathan Wakely
Pushed to trunk now.


On Mon, 8 Apr 2024 at 17:53, Jonathan Wakely  wrote:
>
> Patch v2.
>
> I realised that it's not only negative delim values that cause the
> problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
> will cause traits_type::find to match 'a' but then the eq_int_type
> comparison will fail because (int)'a' != (int)('a' + 256).
>
> This version of the patch calls to_int_type on the delim and if that
> alters the value, it's never going to match so skip the loop that tries
> to find it and just ignore up to n chars instead.
>
> Tested x86_64linux and aarch64-linux.
>
> -- >8 --
>
> A negative delim value passed to std::istream::ignore can never match
> any character in the stream, because the comparison is done using
> traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never returns
> negative values (except at EOF). The optimized version of ignore for the
> std::istream specialization uses traits_type::find to locate the delim
> character in the streambuf, which _can_ match a negative delim on
> platforms where char is signed, but then we do another comparison using
> eq_int_type which fails. The code then keeps looping forever, with
> traits_type::find locating the character and traits_type::eq_int_type
> saying it's not a match, so traits_type::find is used again and finds
> the same character again.
>
> A possible fix would be to check with eq_int_type after a successful
> find, to see whether we really have a match. However, that would be
> suboptimal since we know that a negative delimiter will never match
> using eq_int_type. So a better fix is to adjust the check at the top of
> the function that handles delim==eof(), so that we treat all negative
> delim values as equivalent to EOF. That way we don't bother using find
> to search for something that will never match with eq_int_type.
>
> The version of ignore in the primary template doesn't need a change,
> because it doesn't use traits_type::find, instead characters are
> extracted one-by-one and always matched using eq_int_type. That avoids
> the inconsistency between find and eq_int_type. The specialization for
> std::wistream does use traits_type::find, but traits_type::to_int_type
> is equivalent to an implicit conversion from wchar_t to wint_t, so
> passing a wchar_t directly to ignore without using to_int_type works.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/93672
> * src/c++98/istream.cc (istream::ignore(streamsize, int_type)):
> Treat all negative delimiter values as eof().
> * testsuite/27_io/basic_istream/ignore/char/93672.cc: New test.
> * testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc: New
> test.
> ---
>  libstdc++-v3/src/c++98/istream.cc |  13 ++-
>  .../27_io/basic_istream/ignore/char/93672.cc  | 101 ++
>  .../basic_istream/ignore/wchar_t/93672.cc |  34 ++
>  3 files changed, 146 insertions(+), 2 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
>  create mode 100644 
> libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc
>
> diff --git a/libstdc++-v3/src/c++98/istream.cc 
> b/libstdc++-v3/src/c++98/istream.cc
> index 07ac739c26a..d1bff2b 100644
> --- a/libstdc++-v3/src/c++98/istream.cc
> +++ b/libstdc++-v3/src/c++98/istream.cc
> @@ -112,8 +112,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  basic_istream::
>  ignore(streamsize __n, int_type __delim)
>  {
> -  if (traits_type::eq_int_type(__delim, traits_type::eof()))
> -   return ignore(__n);
> +  {
> +   // If conversion to int_type changes the value then __delim does not
> +   // correspond to a value of type char_type, and so will never match
> +   // a character extracted from the input sequence. Just use ignore(n).
> +   const int_type chk_delim = traits_type::to_int_type(__delim);
> +   const bool matchable = traits_type::eq_int_type(chk_delim, __delim);
> +   if (__builtin_expect(!matchable, 0))
> + return ignore(__n);
> +   // Now we know that __delim is a valid char_type value, so it's safe
> +   // for the code below to use traits_type::find to search for it.
> +  }
>
>_M_gcount = 0;
>sentry __cerb(*this, true);
> diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc 
> b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
> new file mode 100644
> index 000..96737485b83
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
> @@ -0,0 +1,101 @@
> +// { dg-do run }
> +
> +#include 
> +#include 
> +#include 
> +
> 

Re: [PATCH 1/4] libstdc++: Heterogeneous std::pair comparisons [PR113386]

2024-04-15 Thread Jonathan Wakely
Pushed to trunk now.

On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely  wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++20 and later it seems OK for trunk now.
>
> -- >8 --
>
> I'm only treating this as a DR for C++20 for now, because it's less work
> and only requires changes to operator== and operator<=>. To do this for
> older standards would require changes to the six relational operators
> used pre-C++20.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/113386
> * include/bits/stl_pair.h (operator==, operator<=>): Support
> heterogeneous comparisons, as per LWG 3865.
> * testsuite/20_util/pair/comparison_operators/lwg3865.cc: New
> test.
> ---
>  libstdc++-v3/include/bits/stl_pair.h  | 32 ++-
>  .../pair/comparison_operators/lwg3865.cc  | 15 +
>  2 files changed, 39 insertions(+), 8 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
>
> diff --git a/libstdc++-v3/include/bits/stl_pair.h 
> b/libstdc++-v3/include/bits/stl_pair.h
> index 4f5c8389fa6..45317417c9c 100644
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -1000,23 +1000,39 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>template pair(_T1, _T2) -> pair<_T1, _T2>;
>  #endif
>
> -  /// Two pairs of the same type are equal iff their members are equal.
> -  template
> +#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
> +  // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +  // 3865. Sorting a range of pairs
> +
> +  /// Two pairs are equal iff their members are equal.
> +  template
>  inline _GLIBCXX_CONSTEXPR bool
> -operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
> +operator==(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
>  { return __x.first == __y.first && __x.second == __y.second; }
>
> -#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
> -  template
> -constexpr common_comparison_category_t<__detail::__synth3way_t<_T1>,
> -  __detail::__synth3way_t<_T2>>
> -operator<=>(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
> +  /** Defines a lexicographical order for pairs.
> +   *
> +   * For two pairs of comparable types, `P` is ordered before `Q` if
> +   * `P.first` is less than `Q.first`, or if `P.first` and `Q.first`
> +   * are equivalent (neither is less than the other) and `P.second` is
> +   * less than `Q.second`.
> +  */
> +  template
> +constexpr common_comparison_category_t<__detail::__synth3way_t<_T1, _U1>,
> +  __detail::__synth3way_t<_T2, _U2>>
> +operator<=>(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
>  {
>if (auto __c = __detail::__synth3way(__x.first, __y.first); __c != 0)
> return __c;
>return __detail::__synth3way(__x.second, __y.second);
>  }
>  #else
> +  /// Two pairs of the same type are equal iff their members are equal.
> +  template
> +inline _GLIBCXX_CONSTEXPR bool
> +operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
> +{ return __x.first == __y.first && __x.second == __y.second; }
> +
>/** Defines a lexicographical order for pairs.
> *
> * For two pairs of the same type, `P` is ordered before `Q` if
> diff --git 
> a/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc 
> b/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
> new file mode 100644
> index 000..2bbd54af192
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
> @@ -0,0 +1,15 @@
> +// { dg-do run { target c++20 } }
> +
> +// LWG 3865. Sorting a range of pairs
> +
> +#include 
> +#include 
> +
> +int main()
> +{
> +  std::pair p(1, 2);
> +  std::pair p2(p.first, p.second);
> +  VERIFY( p == p2 );
> +  VERIFY( p <= p2 );
> +  VERIFY( p >= p2 );
> +}
> --
> 2.44.0
>



Re: [PATCH 2/4] libstdc++: Add std::reference_wrapper comparison operators for C++26

2024-04-15 Thread Jonathan Wakely
Pushed to trunk now.



On Wed, 10 Apr 2024 at 09:53, Jonathan Wakely  wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++26 it seems OK for trunk now.
>
> -- >8 --
>
> This C++26 change was just approved in Tokyo, in P2944R3. It adds
> operator== and operator<=> overloads to std::reference_wrapper.
>
> The operator<=> overloads in the paper cause compilation errors for any
> type without <=> so they're implemented here with deduced return types
> and constrained by a requires clause.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/refwrap.h (reference_wrapper): Add comparison
> operators as proposed by P2944R3.
> * include/bits/version.def (reference_wrapper): Define.
> * include/bits/version.h: Regenerate.
> * include/std/functional: Enable feature test macro.
> * testsuite/20_util/reference_wrapper/compare.cc: New test.
> ---
>  libstdc++-v3/include/bits/refwrap.h   | 45 +
>  libstdc++-v3/include/bits/version.def |  8 ++
>  libstdc++-v3/include/bits/version.h   | 10 ++
>  libstdc++-v3/include/std/functional   |  1 +
>  .../20_util/reference_wrapper/compare.cc  | 95 +++
>  5 files changed, 159 insertions(+)
>  create mode 100644 
> libstdc++-v3/testsuite/20_util/reference_wrapper/compare.cc
>
> diff --git a/libstdc++-v3/include/bits/refwrap.h 
> b/libstdc++-v3/include/bits/refwrap.h
> index 2d4338b718f..fd1cc2b63e6 100644
> --- a/libstdc++-v3/include/bits/refwrap.h
> +++ b/libstdc++-v3/include/bits/refwrap.h
> @@ -38,6 +38,10 @@
>  #include 
>  #include  // for unary_function and binary_function
>
> +#if __glibcxx_reference_wrapper >= 202403L // >= C++26
> +# include 
> +#endif
> +
>  namespace std _GLIBCXX_VISIBILITY(default)
>  {
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
> @@ -358,6 +362,47 @@ _GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, 
> true_type)
>  #endif
>   return std::__invoke(get(), std::forward<_Args>(__args)...);
> }
> +
> +#if __glibcxx_reference_wrapper >= 202403L // >= C++26
> +  // [refwrap.comparisons], comparisons
> +  [[nodiscard]]
> +  friend constexpr bool
> +  operator==(reference_wrapper __x, reference_wrapper __y)
> +  requires requires { { __x.get() == __y.get() } -> 
> convertible_to; }
> +  { return __x.get() == __y.get(); }
> +
> +  [[nodiscard]]
> +  friend constexpr bool
> +  operator==(reference_wrapper __x, const _Tp& __y)
> +  requires requires { { __x.get() == __y } -> convertible_to; }
> +  { return __x.get() == __y; }
> +
> +  [[nodiscard]]
> +  friend constexpr bool
> +  operator==(reference_wrapper __x, reference_wrapper __y)
> +  requires (!is_const_v<_Tp>)
> +   && requires { { __x.get() == __y.get() } -> convertible_to; }
> +  { return __x.get() == __y.get(); }
> +
> +  [[nodiscard]]
> +  friend constexpr auto
> +  operator<=>(reference_wrapper __x, reference_wrapper<_Tp> __y)
> +  requires requires { __detail::__synth3way(__x.get(), __y.get()); }
> +  { return __detail::__synth3way(__x.get(), __y.get()); }
> +
> +  [[nodiscard]]
> +  friend constexpr auto
> +  operator<=>(reference_wrapper __x, const _Tp& __y)
> +  requires requires { __detail::__synth3way(__x.get(), __y); }
> +  { return __detail::__synth3way(__x.get(), __y); }
> +
> +  [[nodiscard]]
> +  friend constexpr auto
> +  operator<=>(reference_wrapper __x, reference_wrapper __y)
> +  requires (!is_const_v<_Tp>)
> +   && requires { __detail::__synth3way(__x.get(), __y.get()); }
> +  { return __detail::__synth3way(__x.get(), __y.get()); }
> +#endif
>  };
>
>  #if __cpp_deduction_guides
> diff --git a/libstdc++-v3/include/bits/version.def 
> b/libstdc++-v3/include/bits/version.def
> index 5ad44941bff..5c0477fb61e 100644
> --- a/libstdc++-v3/include/bits/version.def
> +++ b/libstdc++-v3/include/bits/version.def
> @@ -1760,6 +1760,14 @@ ftms = {
>};
>  };
>
> +ftms = {
> +  name = reference_wrapper;
> +  values = {
> +v = 202403;
> +cxxmin = 26;
> +  };
> +};
> +
>  ftms = {
>name = saturation_arithmetic;
>values = {
> diff --git a/libstdc++-v3/include/bits/version.h 
> b/libstdc++-v3/include/bits/version.h
> index 460a3e0116a..65e708c73fb 100644
> --- a/libstdc++-v3/include/bits/version.h
> +++ b/libstdc++-v3/include/bits/version.h
> @@ -1963,6 +1963,16 @@
>  #endif /* !defined(__cpp_lib_ratio) && defined(__glibcx

Re: [PATCH] Update GCC 14.1 library versions in docs

2024-04-15 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:51, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When we are already touching this topic, here is a patch like r13-5126
> > which documents the upcoming release symbol versions in the documentation.
> >
> > Ok for trunk?
>
> OK, thanks.
>
> >
> > 2024-04-11  Jakub Jelinek  
> >
> > * doc/xml/manual/abi.xml: Add latest library versions.
> > * doc/html/manual/abi.html: Regenerate.
> >

I'll push this too.
commit 24665d21afd29ac427482243852cb8940bc813d0
Author: Jonathan Wakely 
Date:   Mon Apr 15 16:38:08 2024

libstdc++: Update libstdc++.so versioning history for 14.1.0 release

We can replace "GCC " with "GCC 14.1.0" now that we're nearing the
release.

libstdc++-v3/ChangeLog:

* doc/xml/manual/abi.xml: Replace "" with "14.1.0".
* doc/html/manual/abi.html: Regenerate.

diff --git a/libstdc++-v3/doc/html/manual/abi.html 
b/libstdc++-v3/doc/html/manual/abi.html
index 3075477cc34..0eb6a12a501 100644
--- a/libstdc++-v3/doc/html/manual/abi.html
+++ b/libstdc++-v3/doc/html/manual/abi.html
@@ -110,7 +110,7 @@ compatible.
has the same filename and DT_SONAME as the
preceding release.
   It is versioned as follows:
-GCC 3.0.0: 
libstdc++.so.3.0.0GCC 3.0.1: 
libstdc++.so.3.0.1GCC 3.0.2: 
libstdc++.so.3.0.2GCC 3.0.3: 
libstdc++.so.3.0.2 (See Note 1)GCC 3.0.4: 
libstdc++.so.3.0.4GCC 3.1.0: 
libstdc++.so.4.0.0 (Incompatible with 
previous)GCC 3.1.1: 
libstdc++.so.4.0.1GCC 3.2.0: 
libstdc++.so.5.0.0 (Incompatible with 
previous)GCC 3.2.1: 
libstdc++.so.5.0.1GCC 3.2.2: 
libstdc++.so.5.0.2GCC 3.2.3: 
libstdc++.so.5.0.3 (See Note 2)GCC 3.3.0: 
libstdc++.so.5.0.4GCC 3.3.1: 
libstdc++.so.5.0.5GCC 3.4.0: 
libstdc++.so.6.0.0 (Incompatible with 
previous)GCC 3.4.1: 
libstdc++.so.6.0.1GCC 3.4.2: 
libstdc++.so.6.0.2GCC 3.4.3: 
libstdc++.so.6.0.3GCC 4.0.0: 
libstdc++.so.6.0.4GCC 4.0.1: 
libstdc++.so.6.0.5GCC 4.0.2: 
libstdc++.so.6.0.6GCC 4.0.3: 
libstdc++.so.6.0.7GCC 4.1.0: 
libstdc++.so.6.0.7GCC 4.1.1: 
libstdc++.so.6.0.8GCC 4.2.0: 
libstdc++.so.6.0.9GCC 4.2.1: 
libstdc++.so.6.0.9 (See Note 3)GCC 4.2.2: 
libstdc++.so.6.0.9GCC 4.3.0: 
libstdc++.so.6.0.10GCC 4.4.0: 
libstdc++.so.6.0.11GCC 4.4.1: 
libstdc++.so.6.0.12GCC 4.4.2: 
libstdc++.so.6.0.13GCC 4.5.0: 
libstdc++.so.6.0.14GCC 4.6.0: 
libstdc++.so.6.0.15GCC 4.6.1: 
libstdc++.so.6.0.16GCC 4.7.0: 
libstdc++.so.6.0.17GCC 4.8.0: 
libstdc++.so.6.0.18GCC 4.8.3: 
libstdc++.so.6.0.19GCC 4.9.0: 
libstdc++.so.6.0.20GCC 5.1.0: 
libstdc++.so.6.0.21GCC 6.1.0: 
libstdc++.so.6.0.22GCC 7.1.0: 
libstdc++.so.6.0.23GCC 7.2.0: 
libstdc++.so.6.0.24GCC 8.1.0: 
libstdc++.so.6.0.25GCC 9.1.0: 
libstdc++.so.6.0.26GCC 9.2.0: 
libstdc++.so.6.0.27GCC 9.3.0: 
libstdc++.so.6.0.28GCC 10.1.0: 
libstdc++.so.6.0.28GCC 11.1.0: 
libstdc++.so.6.0.29GCC 12.1.0: 
libstdc++.so.6.0.30GCC 13.1.0: 
libstdc++.so.6.0.31GCC 13.2.0: 
libstdc++.so.6.0.32GCC next: 
libstdc++.so.6.0.33
+GCC 3.0.0: 
libstdc++.so.3.0.0GCC 3.0.1: 
libstdc++.so.3.0.1GCC 3.0.2: 
libstdc++.so.3.0.2GCC 3.0.3: 
libstdc++.so.3.0.2 (See Note 1)GCC 3.0.4: 
libstdc++.so.3.0.4GCC 3.1.0: 
libstdc++.so.4.0.0 (Incompatible with 
previous)GCC 3.1.1: 
libstdc++.so.4.0.1GCC 3.2.0: 
libstdc++.so.5.0.0 (Incompatible with 
previous)GCC 3.2.1: 
libstdc++.so.5.0.1GCC 3.2.2: 
libstdc++.so.5.0.2GCC 3.2.3: 
libstdc++.so.5.0.3 (See Note 2)GCC 3.3.0: 
libstdc++.so.5.0.4GCC 3.3.1: 
libstdc++.so.5.0.5GCC 3.4.0: 
libstdc++.so.6.0.0 (Incompatible with 
previous)GCC 3.4.1: 
libstdc++.so.6.0.1GCC 3.4.2: 
libstdc++.so.6.0.2GCC 3.4.3: 
libstdc++.so.6.0.3GCC 4.0.0: 
libstdc++.so.6.0.4GCC 4.0.1: 
libstdc++.so.6.0.5GCC 4.0.2: 
libstdc++.so.6.0.6GCC 4.0.3: 
libstdc++.so.6.0.7GCC 4.1.0: 
libstdc++.so.6.0.7GCC 4.1.1: 
libstdc++.so.6.0.8GCC 4.2.0: 
libstdc++.so.6.0.9GCC 4.2.1: 
libstdc++.so.6.0.9 (See Note 3)GCC 4.2.2: 
libstdc++.so.6.0.9GCC 4.3.0: 
libstdc++.so.6.0.10GCC 4.4.0: 
libstdc++.so.6.0.11GCC 4.4.1: 
libstdc++.so.6.0.12GCC 4.4.2: 
libstdc++.so.6.0.13GCC 4.5.0: 
libstdc++.so.6.0.14GCC 4.6.0: 
libstdc++.so.6.0.15GCC 4.6.1: 
libstdc++.so.6.0.16GCC 4.7.0: 
libstdc++.so.6.0.17GCC 4.8.0: 
libstdc++.so.6.0.18GCC 4.8.3: 
libstdc++.so.6.0.19GCC 4.9.0: 
libstdc++.so.6.0.20GCC 5.1.0: 
libstdc++.so.6.0.21GCC 6.1.0: 
libstdc++.so.6.0.22GCC 7.1.0: 
libstdc++.so.6.0.23GCC 7.2.0: 
libstdc++.so.6.0.24GCC 8.1.0: 
libstdc++.so.6.0.25GCC 9.1.0: 
libstdc++.so.6.0.26GCC 9.2.0: 
libstdc++.so.6.0.27GCC 9.3.0: 
libstdc++.so.6.0.28GCC 10.1.0: 
libstdc++.so.6.0.28GCC 11.1.0: 
libstdc++.so.6.0.29GCC 12.1.0: 
libstdc++.so.6.0.30GCC 13.1.0: 
libstdc++.so.6.0.31GCC 13.2.0: 
libstdc++.so.6.0.32GCC 14.1.0: 
libstdc++.so.6.0.33
   Note 1: Error should be libstdc++.so.3.0.3.
 
   Note 2: Not strictly required.
diff --git a/libstdc++-v3/doc/xml/manual/abi.xml 
b/libstdc++-v3/doc/xml/manual/abi.xm

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

2024-04-15 Thread Jonathan Wakely
On Mon, 15 Apr 2024 at 14:01, Andreas Schwab wrote:
>
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.

OK for trunk and gcc-13, thanks.

> ---
>  .../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4 
>  1 file changed, 4 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 9423cfb8efc..9229ad33458 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
> @@ -499,6 +499,10 @@ 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_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
>  FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
>  FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
>  FUNC:_ZNKSt12strstreambuf6pcountEv@@GLIBCXX_3.4
> --
> 2.44.0
>
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>



Re: [PATCH] libstdc++: Update some baseline_symbols.txt (x32)

2024-04-12 Thread Jonathan Wakely
On Fri, 12 Apr 2024, 21:51 H.J. Lu,  wrote:

> * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:
> Updated.
>

OK thanks


---
>  .../abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt  | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git
> a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
> b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
> index dc69c47f4d7..ac11d5dba4d 100644
> ---
> a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
> +++
> b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw@@GLIBCXX_3.4
>  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
> @@ -3214,6 +3215,7 @@
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@
> @GLIBCX
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@
> @GLIBCXX_3.4.21
>  FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@
> @GLIBCXX_3.4.21
>  FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@
> @GLIBCXX_3.4.21
>
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@
> @GLIBCXX_3.4.32
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@
> @GLIBCXX_3.4.23
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@
> @GLIBCXX_3.4.21
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@
> @GLIBCXX_3.4.23
> @@ -3366,6 +3368,7 @@
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv@
> @GLIBCX
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@
> @GLIBCXX_3.4.21
>  FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@
> @GLIBCXX_3.4.21
>  FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@
> @GLIBCXX_3.4.21
>
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@
> @GLIBCXX_3.4.32
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@
> @GLIBCXX_3.4.23
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@
> @GLIBCXX_3.4.21
>
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@
> @GLIBCXX_3.4.23
> @@ -4531,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.3
>  FUNC:__cxa_bad_cast@@CXXABI_1.3
>  FUNC:__cxa_bad_typeid@@CXXABI_1.3
>  FUNC:__cxa_begin_catch@@CXXABI_1.3
> +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
>  FUNC:__cxa_call_unexpected@@CXXABI_1.3
>  FUNC:__cxa_current_exception_type@@CXXABI_1.3
>  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> @@ -4574,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
>  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.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4611,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
>  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.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> --
> 2.44.0
>
>


[PATCH] libstdc++: Compile std::allocator instantiations as C++20

2024-04-11 Thread Jonathan Wakely
I'm considering this late patch for gcc-14 to workaround an issue
discovered by a recent Clang change.

I'm not yet sure if Clang is right to require these symbols. It's not
really clear, because always_inline isn't part of the standard so it's
not clear how it should interact with explicit instantiations and
modules. Exporting these four extra symbols doesn't hurt, even if Clang
ends up reverting or revising its change that requires them.

Another way to fix it would be to suppress the explicit instantiation
declarations in  for C++20, so that the compiler
always instantiates them implicitly as needed. We do similar things for
the explicit instantiations of std::string etc. so that new member
functions that aren't in the .so are implicitly instantiated as needed.

That would look like this instead:

--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -281,7 +281,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Inhibit implicit instantiations for required instantiations,
   // which are defined via explicit instantiations elsewhere.
-#if _GLIBCXX_EXTERN_TEMPLATE
+#if _GLIBCXX_EXTERN_TEMPLATE && __cplusplus <= 201703L
   extern template class allocator;
   extern template class allocator;
 #endif

But we might want to export the new functions from the library
eventually anyway, so doing it now (before Clang 19 is released) might
be the best option.

Thoughts?


-- >8 --

This ensures that the new std::allocator::allocate and
std::allocator::deallocate functions are included in the explicit
instantiation definitions. They're only defined for C++20 and later
(because they are needed to support constexpr dynamic allocation) so
were not being instantiated when those files were compiled as C++98.

This isn't needed for GCC because those functions are marked
'always_inline' and so no extern symbols are needed. But a recent Clang
change has meant that always_inline functions do not get exported from
modules, and so the extern symbols (which were not previously being
instantiated or exported) are needed by Clang. See the Clang issue
https://github.com/llvm/llvm-project/issues/86893 for details.

The allocator-inst.cc file is changed to include 
instead of all of , because otherwise it indirectly includes
 and the implicit instantiations of std::string and
std::wstring also instantiate std::allocator and
std::allocator, which for some reason suppresses the explicit
instantiation definitions of the default constructors in this file.
Just including  avoids that problem.

libstdc++-v3/ChangeLog:

* config/abi/pre/gnu.ver: Export new symbols.
* src/c++20/Makefile.am: Add allocator-inst.o.
* src/c++20/Makefile.in: Regenerate.
* src/c++98/allocator-inst.cc: Move to...
* src/c++20/allocator-inst.cc: ...here.
* src/c++98/Makefile.am: Remove allocator-inst.o.
* src/c++98/Makefile.in: Regenerate.
---
 libstdc++-v3/config/abi/pre/gnu.ver | 4 
 libstdc++-v3/src/c++20/Makefile.am  | 1 +
 libstdc++-v3/src/c++20/Makefile.in  | 4 +++-
 libstdc++-v3/src/{c++98 => c++20}/allocator-inst.cc | 2 +-
 libstdc++-v3/src/c++98/Makefile.am  | 1 -
 libstdc++-v3/src/c++98/Makefile.in  | 6 ++
 6 files changed, 11 insertions(+), 7 deletions(-)
 rename libstdc++-v3/src/{c++98 => c++20}/allocator-inst.cc (97%)

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 31449b5b87b..ab001048a67 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2526,6 +2526,10 @@ GLIBCXX_3.4.32 {
 GLIBCXX_3.4.33 {
 # std::basic_file::native_handle()
 _ZNKSt12__basic_fileIcE13native_handleEv;
+
+# std::allocator<[cw]>::allocate and ::deallocate for C++20
+_ZNSaI[cw]E8allocateE[jmy];
+_ZNSaI[cw]E10deallocateEP[cw][jmy];
 } GLIBCXX_3.4.32;
 
 # Symbols in the support library (libsupc++) have their own tag.
diff --git a/libstdc++-v3/src/c++20/Makefile.am 
b/libstdc++-v3/src/c++20/Makefile.am
index a24505e5141..f4a06e6de78 100644
--- a/libstdc++-v3/src/c++20/Makefile.am
+++ b/libstdc++-v3/src/c++20/Makefile.am
@@ -30,6 +30,7 @@ headers =
 if ENABLE_EXTERN_TEMPLATE
 # XTEMPLATE_FLAGS = -fno-implicit-templates
 inst_sources = \
+   allocator-inst.cc \
sstream-inst.cc
 else
 # XTEMPLATE_FLAGS =
diff --git a/libstdc++-v3/src/c++20/Makefile.in 
b/libstdc++-v3/src/c++20/Makefile.in
index 3ec8c5ce804..ec4c5eec026 100644
--- a/libstdc++-v3/src/c++20/Makefile.in
+++ b/libstdc++-v3/src/c++20/Makefile.in
@@ -122,7 +122,8 @@ CONFIG_CLEAN_VPATH_FILES =
 LTLIBRARIES = $(noinst_LTLIBRARIES)
 libc__20convenience_la_LIBADD =
 am__objects_1 = tzdb.lo
-@ENABLE_EXTERN_TEMPLATE_TRUE@am__objects_2 = sstream-inst.lo
+@ENABLE_EXTERN_TEMPLATE_TRUE@am__objects_2 = allocator-inst.lo \
+@ENABLE_EXTERN_TEMPLATE_TRUE@  sstream-inst.lo
 @GLIBCXX_HOSTED_TRUE@am_libc__20convenience_la_OBJECTS =  \
 

Re: [PATCH] Update GCC 14.1 library versions in docs

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
>
> Hi!
>
> When we are already touching this topic, here is a patch like r13-5126
> which documents the upcoming release symbol versions in the documentation.
>
> Ok for trunk?

OK, thanks.

>
> 2024-04-11  Jakub Jelinek  
>
> * doc/xml/manual/abi.xml: Add latest library versions.
> * doc/html/manual/abi.html: Regenerate.
>
> --- gcc/doc/xml/manual/abi.xml.jj   2023-06-12 15:47:22.591501023 +0200
> +++ gcc/doc/xml/manual/abi.xml  2024-04-11 16:43:56.073565349 +0200
> @@ -360,6 +360,7 @@ compatible.
>  GCC 12.1.0: GLIBCXX_3.4.30, 
> CXXABI_1.3.13
>  GCC 13.1.0: GLIBCXX_3.4.31, 
> CXXABI_1.3.14
>  GCC 13.2.0: GLIBCXX_3.4.32, 
> CXXABI_1.3.14
> +GCC 14.1.0: GLIBCXX_3.4.33, 
> CXXABI_1.3.15
>
>  
>  
> --- gcc/doc/html/manual/abi.html.jj 2023-06-12 15:47:22.590501037 +0200
> +++ gcc/doc/html/manual/abi.html2024-04-11 16:45:31.592245629 +0200
> @@ -128,7 +128,7 @@ compatible.
> GLIBCPP_3.2 for symbols that were introduced in the GCC 3.2.0
> release.) If a particular release is not listed, it has the same
> version labels as the preceding release.
> -style="list-style-type: disc; ">GCC 3.0.0: (Error, 
> not versioned)GCC 3.0.1: (Error, not 
> versioned)GCC 3.0.2: (Error, not 
> versioned)GCC 3.0.3: (Error, not 
> versioned)GCC 3.0.4: (Error, not 
> versioned)GCC 3.1.0: GLIBCPP_3.1, 
> CXXABI_1GCC 3.1.1: GLIBCPP_3.1, 
> CXXABI_1GCC 3.2.0: GLIBCPP_3.2, 
> CXXABI_1.2GCC 3.2.1: GLIBCPP_3.2.1, 
> CXXABI_1.2GCC 3.2.2: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.2.3: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.3.0: GLIBCPP_3.2.2, 
> CXXABI_1.2.1GCC 3.3.1: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.2: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.3: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.4.0: GLIBCXX_3.4, 
> CXXABI_1.3GCC 3.4.1: GLIBCXX_3.4.1, 
> CXXABI_1.3GCC 3.4.2: 
> GLIBCXX_3.4.2GCC 3.4.3: 
> GLIBCXX_3.4.3GCC 4.0.0: GLIBCXX_3.4.4, 
> CXXABI_1.3.1GCC 4.0.1: 
> GLIBCXX_3.4.5GCC 4.0.2: 
> GLIBCXX_3.4.6GCC 4.0.3: 
> GLIBCXX_3.4.7GCC 4.1.1: 
> GLIBCXX_3.4.8GCC 4.2.0: 
> GLIBCXX_3.4.9GCC 4.3.0: GLIBCXX_3.4.10, 
> CXXABI_1.3.2GCC 4.4.0: GLIBCXX_3.4.11, 
> CXXABI_1.3.3GCC 4.4.1: GLIBCXX_3.4.12, 
> CXXABI_1.3.3GCC 4.4.2: GLIBCXX_3.4.13, 
> CXXABI_1.3.3GCC 4.5.0: GLIBCXX_3.4.14, 
> CXXABI_1.3.4GCC 4.6.0: GLIBCXX_3.4.15, 
> CXXABI_1.3.5GCC 4.6.1: GLIBCXX_3.4.16, 
> CXXABI_1.3.5GCC 4.7.0: GLIBCXX_3.4.17, 
> CXXABI_1.3.6GCC 4.8.0: GLIBCXX_3.4.18, 
> CXXABI_1.3.7GCC 4.8.3: GLIBCXX_3.4.19, 
> CXXABI_1.3.7GCC 4.9.0: GLIBCXX_3.4.20, 
> CXXABI_1.3.8GCC 5.1.0: GLIBCXX_3.4.21, 
> CXXABI_1.3.9GCC 6.1.0: GLIBCXX_3.4.22, 
> CXXABI_1.3.10GCC 7.1.0: GLIBCXX_3.4.23, 
> CXXABI_1.3.11GCC 7.2.0: GLIBCXX_3.4.24, 
> CXXABI_1.3.11GCC 8.1.0: GLIBCXX_3.4.25, 
> CXXABI_1.3.11GCC 9.1.0: GLIBCXX_3.4.26, 
> CXXABI_1.3.12GCC 9.2.0: GLIBCXX_3.4.27, 
> CXXABI_1.3.12GCC 9.3.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 10.1.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 11.1.0: GLIBCXX_3.4.29, 
> CXXABI_1.3.13GCC 12.1.0: GLIBCXX_3.4.30, 
> CXXABI_1.3.13GCC 13.1.0: GLIBCXX_3.4.31, 
> CXXABI_1.3.14GCC 13.2.0: GLIBCXX_3.4.32, 
> CXXABI_1.3.14Incremental 
> bumping of a compiler pre-defined macro,
> +style="list-style-type: disc; ">GCC 3.0.0: (Error, 
> not versioned)GCC 3.0.1: (Error, not 
> versioned)GCC 3.0.2: (Error, not 
> versioned)GCC 3.0.3: (Error, not 
> versioned)GCC 3.0.4: (Error, not 
> versioned)GCC 3.1.0: GLIBCPP_3.1, 
> CXXABI_1GCC 3.1.1: GLIBCPP_3.1, 
> CXXABI_1GCC 3.2.0: GLIBCPP_3.2, 
> CXXABI_1.2GCC 3.2.1: GLIBCPP_3.2.1, 
> CXXABI_1.2GCC 3.2.2: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.2.3: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.3.0: GLIBCPP_3.2.2, 
> CXXABI_1.2.1GCC 3.3.1: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.2: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.3: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.4.0: GLIBCXX_3.4, 
> CXXABI_1.3GCC 3.4.1: GLIBCXX_3.4.1, 
> CXXABI_1.3GCC 3.4.2: 
> GLIBCXX_3.4.2GCC 3.4.3: 
> GLIBCXX_3.4.3GCC 4.0.0: GLIBCXX_3.4.4, 
> CXXABI_1.3.1GCC 4.0.1: 
> GLIBCXX_3.4.5GCC 4.0.2: 
> GLIBCXX_3.4.6GCC 4.0.3: 
> GLIBCXX_3.4.7GCC 4.1.1: 
> GLIBCXX_3.4.8GCC 4.2.0: 
> GLIBCXX_3.4.9GCC 4.3.0: GLIBCXX_3.4.10, 
> CXXABI_1.3.2GCC 4.4.0: GLIBCXX_3.4.11, 
> CXXABI_1.3.3GCC 4.4.1: GLIBCXX_3.4.12, 
> CXXABI_1.3.3GCC 4.4.2: GLIBCXX_3.4.13, 
> CXXABI_1.3.3GCC 4.5.0: GLIBCXX_3.4.14, 
> CXXABI_1.3.4GCC 4.6.0: GLIBCXX_3.4.15, 
> CXXABI_1.3.5GCC 4.6.1: GLIBCXX_3.4.16, 
> CXXABI_1.3.5GCC 4.7.0: GLIBCXX_3.4.17, 
> CXXABI_1.3.6GCC 4.8.0: GLIBCXX_3.4.18, 
> CXXABI_1.3.7GCC 4.8.3: GLIBCXX_3.4.19, 
> CXXABI_1.3.7GCC 4.9.0: GLIBCXX_3.4.20, 
> CXXABI_1.3.8GCC 5.1.0: GLIBCXX_3.4.21, 
> CXXABI_1.3.9GCC 6.1.0: GLIBCXX_3.4.22, 
> CXXABI_1.3.10GCC 7.1.0: GLIBCXX_3.4.23, 
> CXXABI_1.3.11GCC 7.2.0: GLIBCXX_3.4.24, 
> CXXABI_1.3.11GCC 8.1.0: GLIBCXX_3.4.25, 
> CXXABI_1.3.11GCC 9.1.0: GLIBCXX_3.4.26, 
> CXXABI_1.3.12GCC 9.2.0: GLIBCXX_3.4.27, 
> CXXABI_1.3.12GCC 9.3.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 10.1.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 11.1.0: GLIBCXX_3.4.29, 
> CXXABI_1.3.13GCC 12.1.0: 

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:46, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >
> > If there are other changes needed for m68k, it means it wasn't regenerated
> > properly before the 13.1 release a year ago.
>
> Why do you think this has anything to do with m68k?


Looks like you were pointing out some missing lines for the
riscv64-linux-gnu baseline file, but Jakub's comment still applies.
That arch wasn't in Fedora, so wasn't in his r13-6532-gf875857e008c44
commit.

A riscv64-linux-gnu maintainer should have done that.



Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:36, Andreas Schwab  wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj  
> >   2024-04-11 15:55:49.982325397 +0200
> > +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 
> >   2024-04-11 16:10:05.206559463 +0200
> > @@ -497,6 +497,7 @@ 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:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
> >  FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
> > @@ -4525,6 +4526,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
> >  FUNC:__cxa_bad_cast@@CXXABI_1.3
> >  FUNC:__cxa_bad_typeid@@CXXABI_1.3
> >  FUNC:__cxa_begin_catch@@CXXABI_1.3
> > +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
> >  FUNC:__cxa_call_unexpected@@CXXABI_1.3
> >  FUNC:__cxa_current_exception_type@@CXXABI_1.3
> >  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> > @@ -4568,6 +4570,7 @@ OBJECT:0:CXXABI_1.3.11
> >  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.2
> >  OBJECT:0:CXXABI_1.3.3
> >  OBJECT:0:CXXABI_1.3.4
> > @@ -4604,6 +4607,7 @@ OBJECT:0:GLIBCXX_3.4.3
> >  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.4
> >  OBJECT:0:GLIBCXX_3.4.5
> >  OBJECT:0:GLIBCXX_3.4.6
>
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31


Ah yes, looks like these were added for other arches in
r13-6532-gf875857e008c44 but that didn't include riscv64-linux



Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:18, Jakub Jelinek wrote:
>
> Hi!
>
> While the previous patch was regeneration from 13.2 release (with hand
> edits for arches I don't have libraries for but which are still well
> maintained), thius one is regeneration from the trunk (this time for
> hand edits everywhere for the PR114692
> https://gcc.gnu.org/pipermail/libstdc++/2024-April/058570.html
> patch; plus again hand edits for arches I don't have libraries for).
>
> Ok for trunk after the PR114692 patch is committed?

Yes, OK for trunk now, thanks.


>
> 2024-04-11  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/m68k-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/riscv64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
>
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj 
>   2024-04-11 15:55:49.974325507 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> 2024-04-11 16:01:28.877662971 +0200
> @@ -497,6 +497,7 @@ 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
> @@ -4533,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
>  FUNC:__cxa_bad_cast@@CXXABI_1.3
>  FUNC:__cxa_bad_typeid@@CXXABI_1.3
>  FUNC:__cxa_begin_catch@@CXXABI_1.3
> +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
>  FUNC:__cxa_call_unexpected@@CXXABI_1.3
>  FUNC:__cxa_current_exception_type@@CXXABI_1.3
>  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> @@ -4576,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
>  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.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4613,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
>  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.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 15:55:49.976325479 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt 
>   2024-04-11 16:01:00.085059091 +0200
> @@ -497,6 +497,7 @@ 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
> @@ -4533,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
>  FUNC:__cxa_bad_cast@@CXXABI_1.3
>  FUNC:__cxa_bad_typeid@@CXXABI_1.3
>  FUNC:__cxa_begin_catch@@CXXABI_1.3
> +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
>  FUNC:__cxa_call_unexpected@@CXXABI_1.3
>  FUNC:__cxa_current_exception_type@@CXXABI_1.3
>  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> @@ -4576,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
>  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.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4613,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
>  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.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> --- libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt.jj 
> 2024-04-11 15:55:49.977325466 +0200
> +++ libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt
> 2024-04-11 16:01:00.085059091 +0200
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
>  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:13, Jonathan Wakely  wrote:
>
> On Thu, 11 Apr 2024 at 15:12, Andreas Schwab  wrote:
> >
> > On Apr 11 2024, Jakub Jelinek wrote:
> >
> > > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj   
> > > 2023-05-04 09:42:43.277271065 +0200
> > > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt  
> > > 2024-04-11 15:44:07.113985138 +0200
> > > @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> > > +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> > > @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> > > +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> >
> > That does not fit.
> >
> > 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 975e7e97cbf..0ac915dc01b 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
> > @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw@@GLIBCXX_3.4
> >  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.32
>
> That symbol should not be in this symver, see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html

Jakub's patch is just adding the symbols from gcc-13.2.0 which should
be in the baselines for both gcc-13 and trunk.

After that's done I can fix PR114692 and then we can regen the
baselines for trunk, which will include the
__cxa_call_terminate@@CXXABI_1.3.15 symbol, but also have
_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33 (N.B. 3.4.33
not 3.4.32).



Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:12, Andreas Schwab  wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj 
> >   2023-05-04 09:42:43.277271065 +0200
> > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt  
> > 2024-04-11 15:44:07.113985138 +0200
> > @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> > +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> > @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> > +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
>
> That does not fit.
>
> 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 975e7e97cbf..0ac915dc01b 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
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw@@GLIBCXX_3.4
>  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.32

That symbol should not be in this symver, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html



Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 15:07, Jakub Jelinek wrote:
>
> On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote:
> > I think we also want the same change for i386.
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> >   * config/abi/post/i386-linux-gnu/baseline_symbols.txt:
> >   Regenerate.
>
> Not sure about that, the file is missing all the 3.4.30, 3.4.31 and other
> 3.4.32 symbols as well.
> It needs to be regenerated.

Oh right, yeah there's more missing.

> I'm not really sure what i386 really is and if we support it at all, given
> that it doesn't support the fundamental locking instructions.

True.



[PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

2024-04-11 Thread Jonathan Wakely
I think we also want the same change for i386.

-- >8 --

libstdc++-v3/ChangeLog:

* config/abi/post/i386-linux-gnu/baseline_symbols.txt:
Regenerate.
---
 .../config/abi/post/i386-linux-gnu/baseline_symbols.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
index 259cfdbaaa4..7789f200899 100644
--- a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
@@ -3186,6 +3186,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3337,6 +3338,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
-- 
2.44.0



Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

2024-04-11 Thread Jonathan Wakely
On Thu, 11 Apr 2024 at 14:52, Jakub Jelinek  wrote:
>
> Hi!
>
> The following patch regenerates the ABI files for 13 branch (I've only changed
> the Linux files which were updated in r13-7289, all but m68k, riscv64 and
> powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
> We've added one symbol very early in the 13.2 cycle, but then added 2
> further ones very soon afterwards, quite a long time before 13.2 release
> and haven't regenerated.  The patch applies cleanly to trunk as well.
>
> Ok for trunk/13 branch?

Yes for both, thanks.


>
> 2024-04-11  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/m68k-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/riscv64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
>
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj 
>   2023-05-04 09:42:43.282270993 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> 2024-04-11 15:36:04.251623423 +0200
> @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEmm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEm@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEmmPKwm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEmm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEm@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj  
>   2023-05-04 09:42:43.281271008 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt 
>   2024-04-11 15:36:00.525674901 +0200
> @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> --- libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt.jj 
> 2023-05-04 09:42:43.276271079 +0200
> +++ 

[PATCH] libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33 [PR114692]

2024-04-11 Thread Jonathan Wakely
I plan to push this shortly, to fix the P1 ABI regression that Jakub
reported earlier today.

This will trigger 'make check-abi' failures for CI testers, because the
baseline_sybols.txt wasn't regenerated for gcc 13.2.0 and so there are
two symbols present in GLIBCXX_3.4.32 which are not in the baseline, and
so get flagged as "incompatible" after this change (because new symbols
are not allowed to be added to GLIBCXX_3.4.32 once it's no longer the
latest). That's a false positive, due to the baselines being out of
date. We'll fix that too.

-- >8 --

I added this new symbol in the wrong version. GLIBCXX_3.4.32 was
already used for the GCC 13.2.0 release, so the new symbol should have
been in a new GLIBCXX_3.4.33 version.

Additionally, the pattern doesn't need to use [cw] because we only ever
use __basic_file, even for std::basic_filebuf.

libstdc++-v3/ChangeLog:

PR libstdc++/114692
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Move new exports for
__basic_file::native_handle to ...
(GLIBCXX_3.4.33): ... here. Adjust to not match wchar_t
specialization, which isn't used.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.33 and update
latest version check.
---
 libstdc++-v3/config/abi/pre/gnu.ver  | 9 +++--
 libstdc++-v3/testsuite/util/testsuite_abi.cc | 3 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index db20d75b68e..31449b5b87b 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2516,13 +2516,18 @@ GLIBCXX_3.4.31 {
 
 } GLIBCXX_3.4.30;
 
+# GCC 13.2.0
 GLIBCXX_3.4.32 {
 _ZSt21ios_base_library_initv;
 
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
-# std::basic_file<>::native_handle()
-_ZNKSt12__basic_fileI[cw]E13native_handleEv;
 } GLIBCXX_3.4.31;
 
+# GCC 14.1.0
+GLIBCXX_3.4.33 {
+# std::basic_file::native_handle()
+_ZNKSt12__basic_fileIcE13native_handleEv;
+} GLIBCXX_3.4.32;
+
 # Symbols in the support library (libsupc++) have their own tag.
 CXXABI_1.3 {
 
diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc 
b/libstdc++-v3/testsuite/util/testsuite_abi.cc
index 4f3846b9cc2..e4bf3cdc8e0 100644
--- a/libstdc++-v3/testsuite/util/testsuite_abi.cc
+++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc
@@ -214,6 +214,7 @@ check_version(symbol& test, bool added)
   known_versions.push_back("GLIBCXX_3.4.30");
   known_versions.push_back("GLIBCXX_3.4.31");
   known_versions.push_back("GLIBCXX_3.4.32");
+  known_versions.push_back("GLIBCXX_3.4.33");
   known_versions.push_back("GLIBCXX_LDBL_3.4.31");
   known_versions.push_back("GLIBCXX_IEEE128_3.4.29");
   known_versions.push_back("GLIBCXX_IEEE128_3.4.30");
@@ -253,7 +254,7 @@ 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.32"
+  bool latestp = (test.version_name == "GLIBCXX_3.4.33"
 || test.version_name == "CXXABI_1.3.15"
 || test.version_name == "CXXABI_FLOAT128"
 || test.version_name == "CXXABI_TM_1");
-- 
2.44.0



Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output

2024-04-11 Thread Jonathan Wakely
On Thu, 25 Jan 2024 at 15:54, Christophe Lyon
 wrote:
>
> On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely  wrote:
> >
> > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > >
> > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
> >
> > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> >
>
> Hmm, right, sorry I had this patch in my tree for quite some time, but
> wrote the description just now, so I read a bit too quickly.
>
> >
> > > possibly leading to mismatches under racy conditions.
> >
> > What do we incorrectly match? Is the problem that a \r\n sequence
> > might be incompletely printed, due to buffering, and so the regex only
> > sees (and matches) the \r which then leaves an unwanted \n in the
> > stream, which then interferes with the next match? I don't understand
> > why that problem wouldn't just result in a failed match with your new
> > regex though.
> >
> Exactly: READ1 forces read() to return 1 byte at a time, so we leave
> an unwanted \r in front of a string that should otherwise match the
> "got" case.
>
> >
> > >
> > > I noticed this while running the GCC testsuite using the equivalent of
> > > GDB's READ1 feature [1] which helps detecting bufferization issues.
> > >
> > > Adjusting the first regexp to match the right order implied fixing the
> > > second one, to skip the empty lines.
> >
> > At the very least, this part of the description is misleading. The
> > existing regex matches "the right order" already. The change is to
> > match *exactly* \r\n instead of any mix of CR and LF characters.
> > That's not about matching "the right order", it's being more precise
> > in what we match.
> >
> > But I'm still confused about what the failure scenario is and how the
> > change fixes it.
> >
>
> I followed what the GDB testsuite does (it matches \r\n at the end of
> many regexps), but in fact it seems it's not needed:
> it works if I update the "got" regexp like this (ie. accept any number
> of leading \r or \n):
> -   -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> +   -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> and leave the "skipping" regexp as it is currently.
>
> Is the new attached version OK?

Yeah this makes more sense to me now, thanks.

OK for trunk.


>
> Thanks,
>
> Christophe
>
> > >
> > > Tested on aarch64-linux-gnu.
> > >
> > > [1] 
> > > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> > >
> > > 2024-01-24  Christophe Lyon  
> > >
> > > libstdc++-v3/
> > > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > > ---
> > >  libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp 
> > > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > index 31206f2fc32..0de8d9ee153 100644
> > > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 
> > > 0} } {
> > >
> > >  set test_counter 0
> > >  remote_expect target [timeout_value] {
> > > -   -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > > +   -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > > send_log "got: $expect_out(buffer)"
> > >
> > > incr test_counter
> > > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 
> > > 0} } {
> > > return
> > > }
> > >
> > > -   -re {^[^$][^\n\r]*[\n\r]+} {
> > > +   -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > > send_log "skipping: $expect_out(buffer)"
> > > exp_continue
> > > }
> > > --
> > > 2.34.1
> > >
> >


[committed] libstdc++: Adjust expected locale-dependent date formats in tests

2024-04-10 Thread Jonathan Wakely
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.

-- >8 --

The std/time/year_month_day/io.cc test assumes that %x in the fr_FR
locale is %d/%m/%Y but on FreeBSD it is %d.%m.%Y instead. Make the test
PASS for either format.

Similarly, 27_io/manipulators/extended/get_time/char/2.cc expects that
%a in the de_DE locale is "Di" but on FreeBSD it's "Di." with a trailing
period. Adjust the input string to be "1971 Di." instead of "Di 1971"
and that way if %a doesn't expect the trailing '.' it simply won't
extract it from the stream.

This fixes:
FAIL: std/time/year_month_day/io.cc  -std=gnu++20 execution test
FAIL: 27_io/manipulators/extended/get_time/char/2.cc  -std=gnu++17 execution 
test

libstdc++-v3/ChangeLog:

* testsuite/27_io/manipulators/extended/get_time/char/2.cc:
Adjust input string so that it matches %a with or without a
trailing period.
* testsuite/std/time/year_month_day/io.cc: Adjust expected
format for %x in the fr_FR locale.
---
 .../27_io/manipulators/extended/get_time/char/2.cc  | 6 +++---
 libstdc++-v3/testsuite/std/time/year_month_day/io.cc| 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/2.cc 
b/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/2.cc
index 6104349d254..b582967fddc 100644
--- a/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/2.cc
+++ b/libstdc++-v3/testsuite/27_io/manipulators/extended/get_time/char/2.cc
@@ -35,9 +35,9 @@ void test01()
   VERIFY( loc_de != loc_c );
   istringstream iss;
   iss.imbue(loc_de);
-  iss.str("Di 1971");
-  tm time1;
-  iss >> get_time(, "%a %Y");
+  iss.str("1971 Di."); // %a is "Di" on some targets, "Di." on others.
+  tm time1{};
+  iss >> get_time(, "%Y %a");
   VERIFY(time1.tm_wday == 2);
   VERIFY(time1.tm_year == 71);
 }
diff --git a/libstdc++-v3/testsuite/std/time/year_month_day/io.cc 
b/libstdc++-v3/testsuite/std/time/year_month_day/io.cc
index cb82ef3b612..632b7a0fc2d 100644
--- a/libstdc++-v3/testsuite/std/time/year_month_day/io.cc
+++ b/libstdc++-v3/testsuite/std/time/year_month_day/io.cc
@@ -84,7 +84,7 @@ test_format()
   s = std::format(loc_fr, "{:%x}", 2022y/December/19);
   VERIFY( s == "12/19/22" );
   s = std::format(loc_fr, "{:L%x}", 2022y/December/19);
-  VERIFY( s == "19/12/2022" );
+  VERIFY( s == "19/12/2022" || s == "19.12.2022" ); // depends on locale defs
   s = std::format(loc_fr, "{}", 2022y/December/19);
   VERIFY( s == "2022-12-19" );
   s = std::format(loc_fr, "{:L%F}", 2022y/December/19);
-- 
2.44.0



[committed] libstdc++: Handle EMLINK and EFTYPE in std::filesystem::remove_all

2024-04-10 Thread Jonathan Wakely
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.

-- >8 --

Although POSIX requires ELOOP, FreeBSD documents that openat with
O_NOFOLLOW returns EMLINK if the last component of a filename is a
symbolic link.  Check for EMLINK as well as ELOOP, so that the TOCTTOU
mitigation in remove_all works correctly.

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214633 or the
FreeBSD man page for reference.

According to its man page, DragonFlyBSD also uses EMLINK for this error,
and NetBSD uses its own EFTYPE. OpenBSD follows POSIX and uses EMLINK.

This fixes these failures on FreeBSD:
FAIL: 27_io/filesystem/operations/remove_all.cc  -std=gnu++17 execution test
FAIL: experimental/filesystem/operations/remove_all.cc  -std=gnu++17 execution 
test

libstdc++-v3/ChangeLog:

* src/c++17/fs_ops.cc (remove_all) [__FreeBSD__ || __DragonFly__]:
Check for EMLINK as well as ELOOP.
[__NetBSD__]: Check for EFTYPE as well as ELOOP.
---
 libstdc++-v3/src/c++17/fs_ops.cc | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 61df19753ef..07bc2a0fa88 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -1312,7 +1312,13 @@ fs::remove_all(const path& p)
 // Our work here is done.
 return 0;
   case ENOTDIR:
-  case ELOOP:
+  case ELOOP:  // POSIX says openat with O_NOFOLLOW sets ELOOP for a symlink.
+#if defined __FreeBSD__ || defined __DragonFly__
+  case EMLINK: // Used instead of ELOOP
+#endif
+#if defined __NetBSD__ && defined EFTYPE
+  case EFTYPE: // Used instead of ELOOP
+#endif
 // Not a directory, will remove below.
 break;
 #endif
@@ -1352,7 +1358,13 @@ fs::remove_all(const path& p, error_code& ec)
 ec.clear();
 return 0;
   case ENOTDIR:
-  case ELOOP:
+  case ELOOP:  // POSIX says openat with O_NOFOLLOW sets ELOOP for a symlink.
+#if defined __FreeBSD__ || defined __DragonFly__
+  case EMLINK: // Used instead of ELOOP
+#endif
+#if defined __NetBSD__ && defined EFTYPE
+  case EFTYPE: // Used instead of ELOOP
+#endif
 // Not a directory, will remove below.
 break;
 #endif
-- 
2.44.0



[PATCH 5/4] libstdc++: Rewrite std::variant comparisons without macros

2024-04-10 Thread Jonathan Wakely
I think this is considerably nicer than the macro version, but it can
definitely wait for stage 1.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/variant (__detail::__variant::__compare): New
function template.
(operator==, operator!=, operator<, operator>, operator<=)
(operator>=): Replace macro definition with handwritten function
calling __detail::__variant::__compare.
(operator<=>): Call __detail::__variant::__compare.
---
 libstdc++-v3/include/std/variant | 167 +--
 1 file changed, 114 insertions(+), 53 deletions(-)

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 87a119df8b5..c2277e8831a 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -48,6 +48,7 @@
 #include 
 #include  // in_place_index_t
 #if __cplusplus >= 202002L
+# include 
 # include 
 #endif
 
@@ -1237,47 +1238,119 @@ namespace __variant
 
   struct monostate { };
 
-#if __cpp_lib_concepts
-# define _VARIANT_RELATION_FUNCTION_CONSTRAINTS(TYPES, OP) \
-  requires ((requires (const TYPES& __t) { \
-   { __t OP __t } -> __detail::__boolean_testable; }) && ...)
-#else
-# define _VARIANT_RELATION_FUNCTION_CONSTRAINTS(TYPES, OP)
-#endif
+namespace __detail::__variant
+{
+  template
+constexpr _Ret
+__compare(_Ret __ret, const _Vp& __lhs, const _Vp& __rhs, _Op __op)
+{
+  __variant::__raw_idx_visit(
+   [&__ret, &__lhs, __op] (auto&& __rhs_mem, auto __rhs_index) mutable
+   {
+ if constexpr (__rhs_index != variant_npos)
+   {
+ if (__lhs.index() == __rhs_index.value)
+   {
+ auto& __this_mem = std::get<__rhs_index>(__lhs);
+ __ret = __op(__this_mem, __rhs_mem);
+ return;
+   }
+   }
+ __ret = __op(__lhs.index() + 1, __rhs_index + 1);
+   }, __rhs);
+  return __ret;
+}
+} // namespace __detail::__variant
 
-#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__OP) \
-  template \
-_VARIANT_RELATION_FUNCTION_CONSTRAINTS(_Types, __OP) \
-constexpr bool \
-operator __OP [[nodiscard]] (const variant<_Types...>& __lhs, \
-const variant<_Types...>& __rhs) \
-{ \
-  bool __ret = true; \
-  __detail::__variant::__raw_idx_visit( \
-[&__ret, &__lhs] (auto&& __rhs_mem, auto __rhs_index) mutable \
-{ \
- if constexpr (__rhs_index != variant_npos) \
-   { \
- if (__lhs.index() == __rhs_index) \
-   { \
- auto& __this_mem = std::get<__rhs_index>(__lhs);  \
-  __ret = __this_mem __OP __rhs_mem; \
- return; \
-} \
-} \
- __ret = (__lhs.index() + 1) __OP (__rhs_index + 1); \
-   }, __rhs); \
-  return __ret; \
+  template
+#if __cpp_lib_concepts
+requires ((requires (const _Types& __t) {
+  { __t == __t } -> convertible_to; }) && ...)
+#endif
+constexpr bool
+operator== [[nodiscard]] (const variant<_Types...>& __lhs,
+ const variant<_Types...>& __rhs)
+{
+  return __detail::__variant::__compare(true, __lhs, __rhs,
+   [](auto&& __l, auto&& __r) {
+ return __l == __r;
+   });
 }
 
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(<)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(<=)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(==)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(!=)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(>=)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(>)
+  template
+#if __cpp_lib_concepts
+requires ((requires (const _Types& __t) {
+  { __t != __t } -> convertible_to; }) && ...)
+#endif
+constexpr bool
+operator!= [[nodiscard]] (const variant<_Types...>& __lhs,
+ const variant<_Types...>& __rhs)
+{
+  return __detail::__variant::__compare(true, __lhs, __rhs,
+   [](auto&& __l, auto&& __r) {
+ return __l != __r;
+   });
+}
 
-#undef _VARIANT_RELATION_FUNCTION_TEMPLATE
+  template
+#if __cpp_lib_concepts
+requires ((requires (const _Types& __t) {
+  { __t < __t } -> convertible_to; }) && ...)
+#endif
+constexpr bool
+operator< [[nodiscard]] (const variant<_Types...>& __lhs,
+const variant<_Types...>& __rhs)
+{
+  return __detail::__variant::__compare(true, __lhs, __rhs,
+   [](auto&& __l, auto&& __r) {
+ return __l < __r;
+   });
+}
+
+  template
+#if __cpp_lib_concepts
+requires ((requires (const _Types& __t) {
+  { __t <= __t } -> convertible_to; 

[PATCH 3/4] libstdc++: Constrain equality ops for std::pair, std::tuple, std::variant

2024-04-10 Thread Jonathan Wakely
Tested x86_64-linux.

Since this only affects C++20 and later (except for adding [[nodiscard]]
to relational ops) it seems OK for trunk now.

-- >8 --

Implement the changes from P2944R3 which add constraints to the
comparison operators of std::pair, std::tuple, and std::variant.

The paper also changes std::optional, but we already constrain its
comparisons using SFINAE on the return type. However, we need some
additional constraints on the [optional.comp.with.t] operators that
compare an optional with a value. The paper doesn't say to do that, but
I think it's needed because otherwise when the comparison for two
optional objects fails its constraints, the two overloads that are
supposed to be for comparing to a non-optional become the best overload
candidates, but are ambiguous (and we don't even get as far as checking
the constraints for satisfaction).

The paper does not change std::expected, but probably should have done.
I'll submit an LWG issue about that and implement it separately.

Also add [[nodiscard]] to all these comparison operators.

libstdc++-v3/ChangeLog:

* include/bits/stl_pair.h (operator==): Add constraint.
* include/bits/version.def (constrained_equality): Define.
* include/bits/version.h: Regenerate.
* include/std/optional: Define feature test macro.
(__optional_rep_op_t): Use is_convertible_v instead of
is_convertible.
* include/std/tuple: Define feature test macro.
(operator==, __tuple_cmp, operator<=>): Reimplement C++20
comparisons using lambdas. Add constraints.
* include/std/utility: Define feature test macro.
* include/std/variant: Define feature test macro.
(_VARIANT_RELATION_FUNCTION_TEMPLATE): Add constraints.
(variant): Remove unnecessary friend declarations for comparison
operators.
* testsuite/20_util/optional/relops/constrained.cc: New test.
* testsuite/20_util/pair/comparison_operators/constrained.cc:
New test.
* testsuite/20_util/tuple/comparison_operators/constrained.cc:
New test.
* testsuite/20_util/variant/relops/constrained.cc: New test.
* testsuite/20_util/tuple/comparison_operators/overloaded.cc:
Disable for C++20 and later.
* testsuite/20_util/tuple/comparison_operators/overloaded2.cc:
Remove dg-error line for target c++20.
---
 libstdc++-v3/include/bits/stl_pair.h  |  16 +-
 libstdc++-v3/include/bits/version.def |   9 +
 libstdc++-v3/include/bits/version.h   |  10 +
 libstdc++-v3/include/std/optional |  48 +++-
 libstdc++-v3/include/std/tuple| 102 ---
 libstdc++-v3/include/std/utility  |   1 +
 libstdc++-v3/include/std/variant  |  28 +-
 .../20_util/optional/relops/constrained.cc| 258 ++
 .../pair/comparison_operators/constrained.cc  |  48 
 .../tuple/comparison_operators/constrained.cc |  50 
 .../tuple/comparison_operators/overloaded.cc  |   6 +-
 .../tuple/comparison_operators/overloaded2.cc |   1 -
 .../20_util/variant/relops/constrained.cc | 175 
 13 files changed, 677 insertions(+), 75 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/optional/relops/constrained.cc
 create mode 100644 
libstdc++-v3/testsuite/20_util/pair/comparison_operators/constrained.cc
 create mode 100644 
libstdc++-v3/testsuite/20_util/tuple/comparison_operators/constrained.cc
 create mode 100644 libstdc++-v3/testsuite/20_util/variant/relops/constrained.cc

diff --git a/libstdc++-v3/include/bits/stl_pair.h 
b/libstdc++-v3/include/bits/stl_pair.h
index 45317417c9c..0c1e5719a1a 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -1000,14 +1000,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template pair(_T1, _T2) -> pair<_T1, _T2>;
 #endif
 
-#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
+#if __cpp_lib_three_way_comparison
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 3865. Sorting a range of pairs
 
   /// Two pairs are equal iff their members are equal.
   template
-inline _GLIBCXX_CONSTEXPR bool
+[[nodiscard]]
+constexpr bool
 operator==(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
+requires requires {
+  { __x.first == __y.first } -> __detail::__boolean_testable;
+  { __x.second == __y.second } -> __detail::__boolean_testable;
+}
 { return __x.first == __y.first && __x.second == __y.second; }
 
   /** Defines a lexicographical order for pairs.
@@ -1018,6 +1023,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* less than `Q.second`.
   */
   template
+[[nodiscard]]
 constexpr common_comparison_category_t<__detail::__synth3way_t<_T1, _U1>,
   __detail::__synth3way_t<_T2, _U2>>
 operator<=>(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
@@ -1029,6 +1035,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #else
   /// Two pairs of 

[PATCH 4/4] libstdc++: Simplify std::variant comparison operators

2024-04-10 Thread Jonathan Wakely
Tested x86_64-linux.

This is just a minor clean-up and could wait for stage 1.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/variant (_VARIANT_RELATION_FUNCTION_TEMPLATE):
Simplify.
---
 libstdc++-v3/include/std/variant | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 5ba6d9d42e3..2be0f0c1db7 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1245,7 +1245,7 @@ namespace __variant
 # define _VARIANT_RELATION_FUNCTION_CONSTRAINTS(TYPES, OP)
 #endif
 
-#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__OP, __NAME) \
+#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__OP) \
   template \
 _VARIANT_RELATION_FUNCTION_CONSTRAINTS(_Types, __OP) \
 constexpr bool \
@@ -1262,22 +1262,20 @@ namespace __variant
{ \
  auto& __this_mem = std::get<__rhs_index>(__lhs);  \
   __ret = __this_mem __OP __rhs_mem; \
+ return; \
 } \
- else \
-   __ret = (__lhs.index() + 1) __OP (__rhs_index + 1); \
 } \
-  else \
-__ret = (__lhs.index() + 1) __OP (__rhs_index + 1); \
+ __ret = (__lhs.index() + 1) __OP (__rhs_index + 1); \
}, __rhs); \
   return __ret; \
 }
 
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(<, less)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(<=, less_equal)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(==, equal)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(!=, not_equal)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(>=, greater_equal)
-  _VARIANT_RELATION_FUNCTION_TEMPLATE(>, greater)
+  _VARIANT_RELATION_FUNCTION_TEMPLATE(<)
+  _VARIANT_RELATION_FUNCTION_TEMPLATE(<=)
+  _VARIANT_RELATION_FUNCTION_TEMPLATE(==)
+  _VARIANT_RELATION_FUNCTION_TEMPLATE(!=)
+  _VARIANT_RELATION_FUNCTION_TEMPLATE(>=)
+  _VARIANT_RELATION_FUNCTION_TEMPLATE(>)
 
 #undef _VARIANT_RELATION_FUNCTION_TEMPLATE
 
-- 
2.44.0



[PATCH 2/4] libstdc++: Add std::reference_wrapper comparison operators for C++26

2024-04-10 Thread Jonathan Wakely
Tested x86_64-linux.

Since this only affects C++26 it seems OK for trunk now.

-- >8 --

This C++26 change was just approved in Tokyo, in P2944R3. It adds
operator== and operator<=> overloads to std::reference_wrapper.

The operator<=> overloads in the paper cause compilation errors for any
type without <=> so they're implemented here with deduced return types
and constrained by a requires clause.

libstdc++-v3/ChangeLog:

* include/bits/refwrap.h (reference_wrapper): Add comparison
operators as proposed by P2944R3.
* include/bits/version.def (reference_wrapper): Define.
* include/bits/version.h: Regenerate.
* include/std/functional: Enable feature test macro.
* testsuite/20_util/reference_wrapper/compare.cc: New test.
---
 libstdc++-v3/include/bits/refwrap.h   | 45 +
 libstdc++-v3/include/bits/version.def |  8 ++
 libstdc++-v3/include/bits/version.h   | 10 ++
 libstdc++-v3/include/std/functional   |  1 +
 .../20_util/reference_wrapper/compare.cc  | 95 +++
 5 files changed, 159 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/20_util/reference_wrapper/compare.cc

diff --git a/libstdc++-v3/include/bits/refwrap.h 
b/libstdc++-v3/include/bits/refwrap.h
index 2d4338b718f..fd1cc2b63e6 100644
--- a/libstdc++-v3/include/bits/refwrap.h
+++ b/libstdc++-v3/include/bits/refwrap.h
@@ -38,6 +38,10 @@
 #include 
 #include  // for unary_function and binary_function
 
+#if __glibcxx_reference_wrapper >= 202403L // >= C++26
+# include 
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -358,6 +362,47 @@ _GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, true_type)
 #endif
  return std::__invoke(get(), std::forward<_Args>(__args)...);
}
+
+#if __glibcxx_reference_wrapper >= 202403L // >= C++26
+  // [refwrap.comparisons], comparisons
+  [[nodiscard]]
+  friend constexpr bool
+  operator==(reference_wrapper __x, reference_wrapper __y)
+  requires requires { { __x.get() == __y.get() } -> convertible_to; }
+  { return __x.get() == __y.get(); }
+
+  [[nodiscard]]
+  friend constexpr bool
+  operator==(reference_wrapper __x, const _Tp& __y)
+  requires requires { { __x.get() == __y } -> convertible_to; }
+  { return __x.get() == __y; }
+
+  [[nodiscard]]
+  friend constexpr bool
+  operator==(reference_wrapper __x, reference_wrapper __y)
+  requires (!is_const_v<_Tp>)
+   && requires { { __x.get() == __y.get() } -> convertible_to; }
+  { return __x.get() == __y.get(); }
+
+  [[nodiscard]]
+  friend constexpr auto
+  operator<=>(reference_wrapper __x, reference_wrapper<_Tp> __y)
+  requires requires { __detail::__synth3way(__x.get(), __y.get()); }
+  { return __detail::__synth3way(__x.get(), __y.get()); }
+
+  [[nodiscard]]
+  friend constexpr auto
+  operator<=>(reference_wrapper __x, const _Tp& __y)
+  requires requires { __detail::__synth3way(__x.get(), __y); }
+  { return __detail::__synth3way(__x.get(), __y); }
+
+  [[nodiscard]]
+  friend constexpr auto
+  operator<=>(reference_wrapper __x, reference_wrapper __y)
+  requires (!is_const_v<_Tp>)
+   && requires { __detail::__synth3way(__x.get(), __y.get()); }
+  { return __detail::__synth3way(__x.get(), __y.get()); }
+#endif
 };
 
 #if __cpp_deduction_guides
diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 5ad44941bff..5c0477fb61e 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1760,6 +1760,14 @@ ftms = {
   };
 };
 
+ftms = {
+  name = reference_wrapper;
+  values = {
+v = 202403;
+cxxmin = 26;
+  };
+};
+
 ftms = {
   name = saturation_arithmetic;
   values = {
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index 460a3e0116a..65e708c73fb 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1963,6 +1963,16 @@
 #endif /* !defined(__cpp_lib_ratio) && defined(__glibcxx_want_ratio) */
 #undef __glibcxx_want_ratio
 
+#if !defined(__cpp_lib_reference_wrapper)
+# if (__cplusplus >  202302L)
+#  define __glibcxx_reference_wrapper 202403L
+#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_reference_wrapper)
+#   define __cpp_lib_reference_wrapper 202403L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_reference_wrapper) && 
defined(__glibcxx_want_reference_wrapper) */
+#undef __glibcxx_want_reference_wrapper
+
 #if !defined(__cpp_lib_saturation_arithmetic)
 # if (__cplusplus >  202302L)
 #  define __glibcxx_saturation_arithmetic 202311L
diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 766558b3ce0..99364286a72 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -83,6 +83,7 @@
 #define 

[PATCH 1/4] libstdc++: Heterogeneous std::pair comparisons [PR113386]

2024-04-10 Thread Jonathan Wakely
Tested x86_64-linux.

Since this only affects C++20 and later it seems OK for trunk now.

-- >8 --

I'm only treating this as a DR for C++20 for now, because it's less work
and only requires changes to operator== and operator<=>. To do this for
older standards would require changes to the six relational operators
used pre-C++20.

libstdc++-v3/ChangeLog:

PR libstdc++/113386
* include/bits/stl_pair.h (operator==, operator<=>): Support
heterogeneous comparisons, as per LWG 3865.
* testsuite/20_util/pair/comparison_operators/lwg3865.cc: New
test.
---
 libstdc++-v3/include/bits/stl_pair.h  | 32 ++-
 .../pair/comparison_operators/lwg3865.cc  | 15 +
 2 files changed, 39 insertions(+), 8 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc

diff --git a/libstdc++-v3/include/bits/stl_pair.h 
b/libstdc++-v3/include/bits/stl_pair.h
index 4f5c8389fa6..45317417c9c 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -1000,23 +1000,39 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template pair(_T1, _T2) -> pair<_T1, _T2>;
 #endif
 
-  /// Two pairs of the same type are equal iff their members are equal.
-  template
+#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3865. Sorting a range of pairs
+
+  /// Two pairs are equal iff their members are equal.
+  template
 inline _GLIBCXX_CONSTEXPR bool
-operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
+operator==(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
 { return __x.first == __y.first && __x.second == __y.second; }
 
-#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
-  template
-constexpr common_comparison_category_t<__detail::__synth3way_t<_T1>,
-  __detail::__synth3way_t<_T2>>
-operator<=>(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
+  /** Defines a lexicographical order for pairs.
+   *
+   * For two pairs of comparable types, `P` is ordered before `Q` if
+   * `P.first` is less than `Q.first`, or if `P.first` and `Q.first`
+   * are equivalent (neither is less than the other) and `P.second` is
+   * less than `Q.second`.
+  */
+  template
+constexpr common_comparison_category_t<__detail::__synth3way_t<_T1, _U1>,
+  __detail::__synth3way_t<_T2, _U2>>
+operator<=>(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
 {
   if (auto __c = __detail::__synth3way(__x.first, __y.first); __c != 0)
return __c;
   return __detail::__synth3way(__x.second, __y.second);
 }
 #else
+  /// Two pairs of the same type are equal iff their members are equal.
+  template
+inline _GLIBCXX_CONSTEXPR bool
+operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
+{ return __x.first == __y.first && __x.second == __y.second; }
+
   /** Defines a lexicographical order for pairs.
*
* For two pairs of the same type, `P` is ordered before `Q` if
diff --git 
a/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc 
b/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
new file mode 100644
index 000..2bbd54af192
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
@@ -0,0 +1,15 @@
+// { dg-do run { target c++20 } }
+
+// LWG 3865. Sorting a range of pairs
+
+#include 
+#include 
+
+int main()
+{
+  std::pair p(1, 2);
+  std::pair p2(p.first, p.second);
+  VERIFY( p == p2 );
+  VERIFY( p <= p2 );
+  VERIFY( p >= p2 );
+}
-- 
2.44.0



[committed] libstdc++: Fix build for targets without FP std::from_chars [PR114633]

2024-04-09 Thread Jonathan Wakely
Tested x86_64-linux. Richi confirmed this fixes rx-elf bootstrap.

Pushed to trunk.

-- >8 --

If the faster std::from_chars is not supported for floating-point types
then just extract the value from the stream using operator>>.

This fixes a build error for targets where __cpp_lib_to_chars is not
defined.

libstdc++-v3/ChangeLog:

PR libstdc++/114633
* include/bits/chrono_io.h (_Parser::operator()) <'S'>: Use
stream extraction if std::from_chars is not available.
---
 libstdc++-v3/include/bits/chrono_io.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/bits/chrono_io.h 
b/libstdc++-v3/include/bits/chrono_io.h
index b9eb3d2be53..3b34992b42a 100644
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -3685,6 +3685,7 @@ namespace __detail
  if (!__is_failed(__err)) [[likely]]
{
  long double __val{};
+#if __cpp_lib_to_chars
  string __str = std::move(__buf).str();
  auto __first = __str.data();
  auto __last = __first + __str.size();
@@ -3694,6 +3695,9 @@ namespace __detail
  if ((bool)ec || ptr != __last) [[unlikely]]
__err |= ios_base::failbit;
  else
+#else
+ if (__buf >> __val)
+#endif
{
  duration __fs(__val);
  if constexpr (__is_floating)
-- 
2.44.0



[PATCH v2] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-08 Thread Jonathan Wakely
Patch v2.

I realised that it's not only negative delim values that cause the
problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
will cause traits_type::find to match 'a' but then the eq_int_type
comparison will fail because (int)'a' != (int)('a' + 256).

This version of the patch calls to_int_type on the delim and if that
alters the value, it's never going to match so skip the loop that tries
to find it and just ignore up to n chars instead.

Tested x86_64linux and aarch64-linux.

-- >8 --

A negative delim value passed to std::istream::ignore can never match
any character in the stream, because the comparison is done using
traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never returns
negative values (except at EOF). The optimized version of ignore for the
std::istream specialization uses traits_type::find to locate the delim
character in the streambuf, which _can_ match a negative delim on
platforms where char is signed, but then we do another comparison using
eq_int_type which fails. The code then keeps looping forever, with
traits_type::find locating the character and traits_type::eq_int_type
saying it's not a match, so traits_type::find is used again and finds
the same character again.

A possible fix would be to check with eq_int_type after a successful
find, to see whether we really have a match. However, that would be
suboptimal since we know that a negative delimiter will never match
using eq_int_type. So a better fix is to adjust the check at the top of
the function that handles delim==eof(), so that we treat all negative
delim values as equivalent to EOF. That way we don't bother using find
to search for something that will never match with eq_int_type.

The version of ignore in the primary template doesn't need a change,
because it doesn't use traits_type::find, instead characters are
extracted one-by-one and always matched using eq_int_type. That avoids
the inconsistency between find and eq_int_type. The specialization for
std::wistream does use traits_type::find, but traits_type::to_int_type
is equivalent to an implicit conversion from wchar_t to wint_t, so
passing a wchar_t directly to ignore without using to_int_type works.

libstdc++-v3/ChangeLog:

PR libstdc++/93672
* src/c++98/istream.cc (istream::ignore(streamsize, int_type)):
Treat all negative delimiter values as eof().
* testsuite/27_io/basic_istream/ignore/char/93672.cc: New test.
* testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc: New
test.
---
 libstdc++-v3/src/c++98/istream.cc |  13 ++-
 .../27_io/basic_istream/ignore/char/93672.cc  | 101 ++
 .../basic_istream/ignore/wchar_t/93672.cc |  34 ++
 3 files changed, 146 insertions(+), 2 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc

diff --git a/libstdc++-v3/src/c++98/istream.cc 
b/libstdc++-v3/src/c++98/istream.cc
index 07ac739c26a..d1bff2b 100644
--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -112,8 +112,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 basic_istream::
 ignore(streamsize __n, int_type __delim)
 {
-  if (traits_type::eq_int_type(__delim, traits_type::eof()))
-   return ignore(__n);
+  {
+   // If conversion to int_type changes the value then __delim does not
+   // correspond to a value of type char_type, and so will never match
+   // a character extracted from the input sequence. Just use ignore(n).
+   const int_type chk_delim = traits_type::to_int_type(__delim);
+   const bool matchable = traits_type::eq_int_type(chk_delim, __delim);
+   if (__builtin_expect(!matchable, 0))
+ return ignore(__n);
+   // Now we know that __delim is a valid char_type value, so it's safe
+   // for the code below to use traits_type::find to search for it.
+  }
 
   _M_gcount = 0;
   sentry __cerb(*this, true);
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
new file mode 100644
index 000..96737485b83
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
@@ -0,0 +1,101 @@
+// { dg-do run }
+
+#include 
+#include 
+#include 
+
+void
+test_pr93672() // std::basic_istream::ignore hangs if delim MSB is set
+{
+  std::istringstream in(".\xfc..\xfd...\xfe.");
+
+  // This should find '\xfd' even on platforms where char is signed,
+  // because the delimiter is correctly converted to the stream's int_type.
+  in.ignore(100, std::char_traits::to_int_type('\xfc'));
+  VERIFY( in.gcount() == 2 );
+  VERIFY( ! in.eof() );
+
+  // This should work equivalently to traits_type::to_int_type
+  in.ignore(100, (unsigned char)'\xfd');
+  VERIFY( in.gcount() == 3 );
+  VERIFY( ! in.eof() );
+
+  // This only 

[committed] libstdc++: Use char for _Utf8_view if char8_t isn't available [PR114519]

2024-04-08 Thread Jonathan Wakely
I recently disabled _Utf8_view for -fno-char8_t, but we can just make it
use char instead of char8_t. The existing uses of it in the library are
unaffected.

Tested x86_64-linux and aarch64-linux. Pushed to trunk.

-- >8 --

Instead of just omitting the definition of __unicode::_Utf8_view when
char8_t is disabled, we can make it use char instead.

libstdc++-v3/ChangeLog:

PR libstdc++/114519
* include/bits/unicode.h (_Utf8_view) [!__cpp_char8_t]: Define
using char instead of char8_t.
* testsuite/ext/unicode/view.cc: Use u8""sv literals to create
string views, instead of std::u8string_view.
---
 libstdc++-v3/include/bits/unicode.h| 3 +++
 libstdc++-v3/testsuite/ext/unicode/view.cc | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/bits/unicode.h 
b/libstdc++-v3/include/bits/unicode.h
index 0e95c86a0b0..29813b743dc 100644
--- a/libstdc++-v3/include/bits/unicode.h
+++ b/libstdc++-v3/include/bits/unicode.h
@@ -581,6 +581,9 @@ namespace __unicode
 #ifdef __cpp_char8_t
   template
 using _Utf8_view = _Utf_view;
+#else
+  template
+using _Utf8_view = _Utf_view;
 #endif
   template
 using _Utf16_view = _Utf_view;
diff --git a/libstdc++-v3/testsuite/ext/unicode/view.cc 
b/libstdc++-v3/testsuite/ext/unicode/view.cc
index 79ea2bbc6b7..ee23b0b1d8a 100644
--- a/libstdc++-v3/testsuite/ext/unicode/view.cc
+++ b/libstdc++-v3/testsuite/ext/unicode/view.cc
@@ -10,7 +10,7 @@ using namespace std::string_view_literals;
 constexpr void
 test_utf8_to_utf8()
 {
-  const std::u8string_view s8 = u8"£🇬🇧 €🇪🇺 æбçδé ♠
♥♦♣ 🤡";
+  const auto s8 = u8"£🇬🇧 €🇪🇺 æбçδé ♠♥♦♣ 🤡"sv;
   uc::_Utf8_view v(s8);
   VERIFY( std::ranges::distance(v) == s8.size() );
   VERIFY( std::ranges::equal(v,  s8) );
@@ -19,7 +19,7 @@ test_utf8_to_utf8()
 constexpr void
 test_utf8_to_utf16()
 {
-  const std::u8string_view s8  = u8"£🇬🇧 €🇪🇺 æбçδé ♠
♥♦♣ 🤡";
+  const auto s8  = u8"£🇬🇧 €🇪🇺 æбçδé ♠♥♦♣ 🤡"sv;
   const std::u16string_view s16 = u"£🇬🇧 €🇪🇺 æбçδé ♠
♥♦♣ 🤡";
   uc::_Utf16_view v(s8);
   VERIFY( std::ranges::distance(v) == s16.size() );
-- 
2.44.0



[committed] libstdc++: Fix tests that fail with -fno-char8_t

2024-04-08 Thread Jonathan Wakely
Tested x86_64-linux and aarch64-linux. Pushed to trunk.

-- >8 --

Adjust expected errors or skip tests as UNSUPPORTED if -fno-char8_t is
used in the test flags.

libstdc++-v3/ChangeLog:

* testsuite/20_util/integer_comparisons/equal_neg.cc: Use
no-opts selector for errors that depend on -fchar8_t.
* testsuite/20_util/integer_comparisons/greater_equal_neg.cc:
Likewise.
* testsuite/20_util/integer_comparisons/greater_neg.cc:
Likewise.
* testsuite/20_util/integer_comparisons/in_range_neg.cc:
Likewise.
* testsuite/20_util/integer_comparisons/less_equal_neg.cc:
Likewise.
* testsuite/20_util/integer_comparisons/less_neg.cc: Likewise.
* testsuite/20_util/integer_comparisons/not_equal_neg.cc:
Likewise.
* testsuite/21_strings/basic_string/hash/hash_char8_t.cc: Skip
if -fno-char8_t is used.
* testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_character/char/deleted.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_character/wchar_t/deleted.cc:
Likewise.
* testsuite/27_io/filesystem/path/factory/u8path-depr.cc: Use
char for u8 literal if char8_t is not available.
* testsuite/27_io/headers/iosfwd/synopsis.cc: Check
__cpp_char8_t.
* testsuite/29_atomics/atomic_integral/wait_notify.cc: Likewise.
* testsuite/29_atomics/headers/atomic/types_std_c++20_neg.cc:
Remove check for _GLIBCXX_USE_CHAR8_T.
---
 .../testsuite/20_util/integer_comparisons/equal_neg.cc  | 4 ++--
 .../20_util/integer_comparisons/greater_equal_neg.cc| 4 ++--
 .../testsuite/20_util/integer_comparisons/greater_neg.cc| 4 ++--
 .../testsuite/20_util/integer_comparisons/in_range_neg.cc   | 6 --
 .../testsuite/20_util/integer_comparisons/less_equal_neg.cc | 4 ++--
 .../testsuite/20_util/integer_comparisons/less_neg.cc   | 4 ++--
 .../testsuite/20_util/integer_comparisons/not_equal_neg.cc  | 4 ++--
 .../testsuite/21_strings/basic_string/hash/hash_char8_t.cc  | 1 +
 .../21_strings/headers/cuchar/functions_std_cxx20.cc| 1 +
 .../27_io/basic_ostream/inserters_character/char/deleted.cc | 1 +
 .../basic_ostream/inserters_character/wchar_t/deleted.cc| 1 +
 .../testsuite/27_io/filesystem/path/factory/u8path-depr.cc  | 4 +++-
 libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc | 2 +-
 .../testsuite/29_atomics/atomic_integral/wait_notify.cc | 2 ++
 .../29_atomics/headers/atomic/types_std_c++20_neg.cc| 2 --
 15 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/integer_comparisons/equal_neg.cc 
b/libstdc++-v3/testsuite/20_util/integer_comparisons/equal_neg.cc
index 06cfd6ee8f4..7290e9e2417 100644
--- a/libstdc++-v3/testsuite/20_util/integer_comparisons/equal_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/integer_comparisons/equal_neg.cc
@@ -25,8 +25,8 @@ bool c = std::cmp_equal(2, L'2'); // { dg-error "here" }
 bool d = std::cmp_equal(L'2', 2); // { dg-error "here" }
 bool e = std::cmp_equal(true, 1); // { dg-error "here" }
 bool f = std::cmp_equal(0, false); // { dg-error "here" }
-bool g = std::cmp_equal(97, u8'a'); // { dg-error "here" }
-bool h = std::cmp_equal(u8'a', 97); // { dg-error "here" }
+bool g = std::cmp_equal(97, u8'a'); // { dg-error "here" "" { target { no-opts 
"-fno-char8_t" } } }
+bool h = std::cmp_equal(u8'a', 97); // { dg-error "here" "" { target { no-opts 
"-fno-char8_t" } } }
 bool i = std::cmp_equal(97, u'a'); // { dg-error "here" }
 bool j = std::cmp_equal(u'a', 97); // { dg-error "here" }
 bool k = std::cmp_equal(97, U'a'); // { dg-error "here" }
diff --git 
a/libstdc++-v3/testsuite/20_util/integer_comparisons/greater_equal_neg.cc 
b/libstdc++-v3/testsuite/20_util/integer_comparisons/greater_equal_neg.cc
index b5f03b70733..cb60bfe9d07 100644
--- a/libstdc++-v3/testsuite/20_util/integer_comparisons/greater_equal_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/integer_comparisons/greater_equal_neg.cc
@@ -25,8 +25,8 @@ bool c = std::cmp_greater_equal(2, L'2'); // { dg-error 
"constexpr" }
 bool d = std::cmp_greater_equal(L'2', 2); // { dg-error "constexpr" }
 bool e = std::cmp_greater_equal(true, 1); // { dg-error "constexpr" }
 bool f = std::cmp_greater_equal(0, false); // { dg-error "constexpr" }
-bool g = std::cmp_greater_equal(97, u8'a'); // { dg-error "constexpr" }
-bool h = std::cmp_greater_equal(u8'a', 97); // { dg-error "constexpr" }
+bool g = std::cmp_greater_equal(97, u8'a'); // { dg-error "constexpr" "" { 
target { no-opts "-fno-char8_t" } } }
+bool h = std::cmp_greater_equal(u8'a', 97); // { dg-error "constexpr" "" { 
target { no-opts "-fno-char8_t" } } }
 bool i = std::cmp_greater_equal(97, u'a'); // { dg-error "constexpr" }
 bool j = std::cmp_greater_equal(u'a', 97); // { dg-error "constexpr" }
 bool k = std::cmp_greater_equal(97, U'a'); // { dg-error 

[committed] libstdc++: Combine two std::from_chars tests into one

2024-04-08 Thread Jonathan Wakely
Tested x86_64-linux and aarch64-linux. Pushed to trunk.

-- >8 --

We don't need separate tests for the C++17 and C++20 cases, we can just
have one test that uses __cpp_char8_t to adjust whether it tests char8_t
or not. This means the C++20 one doesn't fail if -fno-char8_t is used.

libstdc++-v3/ChangeLog:

* testsuite/20_util/from_chars/1_neg.cc: Add char8_t cases,
using a struct of that name if -fno-char8_t is active.
* testsuite/20_util/from_chars/1_c++20_neg.cc: Removed.
---
 .../20_util/from_chars/1_c++20_neg.cc | 43 ---
 .../testsuite/20_util/from_chars/1_neg.cc |  7 +++
 2 files changed, 7 insertions(+), 43 deletions(-)
 delete mode 100644 libstdc++-v3/testsuite/20_util/from_chars/1_c++20_neg.cc

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/1_c++20_neg.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/1_c++20_neg.cc
deleted file mode 100644
index d246eefb469..000
--- a/libstdc++-v3/testsuite/20_util/from_chars/1_c++20_neg.cc
+++ /dev/null
@@ -1,43 +0,0 @@
-// Copyright (C) 2017-2024 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library.  This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 3, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING3.  If not see
-// .
-
-// { dg-do compile { target c++20 } }
-
-#include 
-
-void
-test01(const char* first, const char* last)
-{
-  wchar_t wc;
-  std::from_chars(first, last, wc); // { dg-error "no matching" }
-  std::from_chars(first, last, wc, 10); // { dg-error "no matching" }
-  char8_t c8;
-  std::from_chars(first, last, c8); // { dg-error "no matching" }
-  std::from_chars(first, last, c8, 10); // { dg-error "no matching" }
-  char16_t c16;
-  std::from_chars(first, last, c16); // { dg-error "no matching" }
-  std::from_chars(first, last, c16, 10); // { dg-error "no matching" }
-  char32_t c32;
-  std::from_chars(first, last, c32); // { dg-error "no matching" }
-  std::from_chars(first, last, c32, 10); // { dg-error "no matching" }
-  enum E { } e;
-  std::from_chars(first, last, e); // { dg-error "no matching" }
-  std::from_chars(first, last, e, 10); // { dg-error "no matching" }
-}
-
-// { dg-prune-output "enable_if" }
-// { dg-prune-output "cannot bind non-const lvalue reference" }
diff --git a/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc
index 7538d9448ac..3f4cd59f6fc 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc
@@ -36,6 +36,13 @@ test01(const char* first, const char* last)
   enum E { } e;
   std::from_chars(first, last, e); // { dg-error "no matching" }
   std::from_chars(first, last, e, 10); // { dg-error "no matching" }
+
+#ifndef __cpp_char8_t
+  struct char8_t { };
+#endif
+  char8_t c8;
+  std::from_chars(first, last, c8); // { dg-error "no matching" }
+  std::from_chars(first, last, c8, 10); // { dg-error "no matching" }
 }
 
 // { dg-prune-output "enable_if" }
-- 
2.44.0



Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-04 Thread Jonathan Wakely
On Thu, 4 Apr 2024 at 17:55, Jonathan Wakely  wrote:
>
> On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely  wrote:
> Ulrich's suggestion is to allow the buggy user code to Just Work (for
> all cases except (char)-1 on a platform where char is signed). That is
> maybe the least surprising behaviour for users.
>
> On the other hand, I'm not sure we really want to support:
>
> cin.ignore(n, -10);
> cin.ignore(n, -999);
> cin.ignore(n, +999);
>
> What are these trying to do? Those are just nonsense arguments to this
> function. But if we try to make the testcase in the bug report Just
> Work, we end up also accepting (at least) the -10 case, because it's
> indistinguishable from the char '\xf6'. Depending how we do it, we
> might also make the other cases work, treating -999 as '\x19', and
> +999 as '\xe7'.

So maybe what we want is to add a new overload:

basic_istream&
ignore(streamsize n, char_type c)
{
  return ignore(n, traits_type::to_int_type(c));
}

This will only accept the stream's char_type, not -999 or +999, and
will do the required conversion to int_type correctly, not as an
implicit conversion.

Calls that pass eof() will still select the other overload and do the
right thing. Calls using a char (or for wstream, a wchar_t) will
select the new overload.

This new overload will make some calls ambiguous, e.g. ignore(1, 1L)
compiles today, but would become ambiguous. That seems fine, since the
second argument should not be type long (what is it even trying to
do?)

If that's a problem, we can make it a constrained template that only
gets called for the exact char_type:

basic_istream&
ignore(streamsize n, same_as auto c)

This would still Do The Right Thing for ignore(n, '\x80') but would
not change the result of ignore(1, 1L) which would still select the
original overload taking int_type for the second parameter.

I think I'll raise this idea with the committee. For now though, I
think my patch fixes the bug and conforms to the standard, and doesn't
do anything inventive.



Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-04 Thread Jonathan Wakely
On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely  wrote:
>
> On Thu, 4 Apr 2024 at 16:40, Iain Sandoe  wrote:
> >
> >
> >
> > > On 4 Apr 2024, at 16:29, Jonathan Wakely  wrote:
> > >
> > > I would appreciate more eyes on this to confirm my conclusions about
> > > negative int_type values, and the proposed fix, make sense.
> > >
> > > Tested x86_64-linux.
> > >
> > > -- >8 --
> > >
> > > A negative value for the delim value passed to std::istream::ignore can
> > > never match any character in the stream, because the comparison is done
> > > using traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never
> > > returns negative values (except at EOF). The optimized version of
> > > ignore for the std::istream specialization uses traits_type::find to
> > > locate the delim character in the streambuf, which _can_ match a
> > > negative delim on platforms where char is signed, but then we do another
> > > comparison using eq_int_type which fails. The code then keeps looping
> > > forever, with traits_type::find saying the character is present and
> > > eq_int_type saying it's not.
> > >
> > > A possible fix would be to check with eq_int_type after a successful
> > > find, to see whether we really have a match. However, that would be
> > > suboptimal since we know that a negative delimiter will never match
> > > using eq_int_type. So a better fix is to adjust the check at the top of
> > > the function that handles delim==eof(), so that we treat all negative
> > > delim values as equivalent to EOF. That way we don't bother using find
> > > to search for something that will never match with eq_int_type.
> >
> > Is the corollary to this that a platform with signed chars can never use a
> > negative value as a delimiter - since that we always be treated as EOF?
>
> That's what the C++ standard says (and is what libc++ does).
>
> The delimiter argument to ignore is an int_type, not a char. So
> formally you should call it like:
>
> std::cin.ignore(n, std::istream::traits_type::to_int_type('a'));
>
> where to_int_type will cast to unsigned char and then to int, so that
> no char can ever produce a negative value for that argument.
>
> If you happen to know that casting 'a' to unsigned char and then to
> int doesn't change its value (because it's a 7-bit ASCII value), then
> you can be lazy and do:
>
> std::cin.ignore(n, 'a');
>
> That works fine.
>
> But if your delimiter character is the MSB set, *and* char is signed
> on your platform, then you can't be lazy. The implicit conversion from
> char to the stream's int_type is not the same as the result of calling
> traits_type::to_int_type, and so these are NOT equivalent on a
> platform with signed char:
> std::cin.ignore(n, '\x80');
> std::cin.ignore(n, (unsigned char)'\x80');
>
> The former is wrong, the latter is correct.
> The former will never match a '\x80' in the stream, because the ignore
> function will cast each char extracted from the stream to
> (int)(unsigned char) and so never match -128.
>
> So the change to treat all negative values as EOF is just an
> optimization. Since they can never match, there's no point searching
> for them. Just skip n chars.

And FWIW, I don't think libc++ does that optimization. They extract
char-by-char and compare them, even though that can never match a
negative value. So they get the same result as with my patch, but much
slower ;-)

The status quo is that libstdc++ loops forever given a negative
delimiter. That's obviously wrong!

We need to fix the buggy logic that loops forever, and the "correct"
standard conforming fix means that we never match the negative value,
because the chars are extracted from the stream as non-negative
int_type values. As an optimization, we can skip the loop that keeps
trying impossible matches, because we know it won't match. That's what
my patch does. (It occurs to me now that we could also treat any delim
value greater than 255 as EOF too, since that can't match either).

Ulrich's suggestion is to allow the buggy user code to Just Work (for
all cases except (char)-1 on a platform where char is signed). That is
maybe the least surprising behaviour for users.

On the other hand, I'm not sure we really want to support:

cin.ignore(n, -10);
cin.ignore(n, -999);
cin.ignore(n, +999);

What are these trying to do? Those are just nonsense arguments to this
function. But if we try to make the testcase in the bug report Just
Work, we end up also accepting (at least) the -10 case, because it's
indistinguishable from the char '\xf6'. Depending how we do it, we
might also make the other cases work, treating -999 as '\x19', and
+999 as '\xe7'.



Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-04 Thread Jonathan Wakely
On Thu, 4 Apr 2024 at 17:33, Jonathan Wakely  wrote:
>
> On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper  wrote:
> >
> > On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely  wrote:
> > > I would appreciate more eyes on this to confirm my conclusions about
> > > negative int_type values, and the proposed fix, make sense.
> >
> > The way something like this is handled in glibc's ctype functions is
> > that both branches are considered.  For isXXX(c) whether c is -v or
> > 256-v the same value is returned (except for EOF which is -1).  This
> > caused the least number of bad surprises.
> >
> > You could here also perform similar actions.
>
> Yes, my first attempt to fix PR93672 did exactly that, see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672#c1
>
> But since it doesn't work for '\xff' (because that's EOF when char is
> signed) it only handles 127 of the 128 possible bugs ;-)
> I'm also not sure it's conforming, since the standard specifies how
> the matching is done, and that won't match negative chars.

I might suggest relaxing the standard to allow it though...



Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-04 Thread Jonathan Wakely
On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper  wrote:
>
> On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely  wrote:
> > I would appreciate more eyes on this to confirm my conclusions about
> > negative int_type values, and the proposed fix, make sense.
>
> The way something like this is handled in glibc's ctype functions is
> that both branches are considered.  For isXXX(c) whether c is -v or
> 256-v the same value is returned (except for EOF which is -1).  This
> caused the least number of bad surprises.
>
> You could here also perform similar actions.

Yes, my first attempt to fix PR93672 did exactly that, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672#c1

But since it doesn't work for '\xff' (because that's EOF when char is
signed) it only handles 127 of the 128 possible bugs ;-)
I'm also not sure it's conforming, since the standard specifies how
the matching is done, and that won't match negative chars.



Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-04 Thread Jonathan Wakely
On Thu, 4 Apr 2024 at 16:40, Iain Sandoe  wrote:
>
>
>
> > On 4 Apr 2024, at 16:29, Jonathan Wakely  wrote:
> >
> > I would appreciate more eyes on this to confirm my conclusions about
> > negative int_type values, and the proposed fix, make sense.
> >
> > Tested x86_64-linux.
> >
> > -- >8 --
> >
> > A negative value for the delim value passed to std::istream::ignore can
> > never match any character in the stream, because the comparison is done
> > using traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never
> > returns negative values (except at EOF). The optimized version of
> > ignore for the std::istream specialization uses traits_type::find to
> > locate the delim character in the streambuf, which _can_ match a
> > negative delim on platforms where char is signed, but then we do another
> > comparison using eq_int_type which fails. The code then keeps looping
> > forever, with traits_type::find saying the character is present and
> > eq_int_type saying it's not.
> >
> > A possible fix would be to check with eq_int_type after a successful
> > find, to see whether we really have a match. However, that would be
> > suboptimal since we know that a negative delimiter will never match
> > using eq_int_type. So a better fix is to adjust the check at the top of
> > the function that handles delim==eof(), so that we treat all negative
> > delim values as equivalent to EOF. That way we don't bother using find
> > to search for something that will never match with eq_int_type.
>
> Is the corollary to this that a platform with signed chars can never use a
> negative value as a delimiter - since that we always be treated as EOF?

That's what the C++ standard says (and is what libc++ does).

The delimiter argument to ignore is an int_type, not a char. So
formally you should call it like:

std::cin.ignore(n, std::istream::traits_type::to_int_type('a'));

where to_int_type will cast to unsigned char and then to int, so that
no char can ever produce a negative value for that argument.

If you happen to know that casting 'a' to unsigned char and then to
int doesn't change its value (because it's a 7-bit ASCII value), then
you can be lazy and do:

std::cin.ignore(n, 'a');

That works fine.

But if your delimiter character is the MSB set, *and* char is signed
on your platform, then you can't be lazy. The implicit conversion from
char to the stream's int_type is not the same as the result of calling
traits_type::to_int_type, and so these are NOT equivalent on a
platform with signed char:
std::cin.ignore(n, '\x80');
std::cin.ignore(n, (unsigned char)'\x80');

The former is wrong, the latter is correct.
The former will never match a '\x80' in the stream, because the ignore
function will cast each char extracted from the stream to
(int)(unsigned char) and so never match -128.

So the change to treat all negative values as EOF is just an
optimization. Since they can never match, there's no point searching
for them. Just skip n chars.



>
> - I am not sure it there’s an actual use-case where that matters, but,
> Iain
>
> >
> > The version of ignore in the primary template doesn't need a change,
> > because it doesn't use traits_type::find, instead characters are
> > extracted one-by-one and always matched using eq_int_type. That avoids
> > the inconsistency between find and eq_int_type.
> >
> > libstdc++-v3/ChangeLog:
> >
> >   PR libstdc++/93672
> >   * src/c++98/istream.cc (istream::ignore(streamsize, int_type)):
> >   Treat all negative delimiter values as eof().
> >   * testsuite/27_io/basic_istream/ignore/char/93672.cc: New test.
> > ---
> > libstdc++-v3/src/c++98/istream.cc |  5 -
> > .../27_io/basic_istream/ignore/char/93672.cc  | 15 +++
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> > create mode 100644 
> > libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
> >
> > diff --git a/libstdc++-v3/src/c++98/istream.cc 
> > b/libstdc++-v3/src/c++98/istream.cc
> > index 07ac739c26a..aa1069dea07 100644
> > --- a/libstdc++-v3/src/c++98/istream.cc
> > +++ b/libstdc++-v3/src/c++98/istream.cc
> > @@ -112,7 +112,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > basic_istream::
> > ignore(streamsize __n, int_type __delim)
> > {
> > -  if (traits_type::eq_int_type(__delim, traits_type::eof()))
> > +  // sgetc() returns either (int_type)(unsigned char)c or -1 for EOF.
> > +  // If __delim is negative, then eq_int_type(sgetc(), __delim) can 
> > only
> > +  // be true for EOF, so just treat all negative values as eof().
> > +  

[PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

2024-04-04 Thread Jonathan Wakely
I would appreciate more eyes on this to confirm my conclusions about
negative int_type values, and the proposed fix, make sense.

Tested x86_64-linux.

-- >8 --

A negative value for the delim value passed to std::istream::ignore can
never match any character in the stream, because the comparison is done
using traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never
returns negative values (except at EOF). The optimized version of
ignore for the std::istream specialization uses traits_type::find to
locate the delim character in the streambuf, which _can_ match a
negative delim on platforms where char is signed, but then we do another
comparison using eq_int_type which fails. The code then keeps looping
forever, with traits_type::find saying the character is present and
eq_int_type saying it's not.

A possible fix would be to check with eq_int_type after a successful
find, to see whether we really have a match. However, that would be
suboptimal since we know that a negative delimiter will never match
using eq_int_type. So a better fix is to adjust the check at the top of
the function that handles delim==eof(), so that we treat all negative
delim values as equivalent to EOF. That way we don't bother using find
to search for something that will never match with eq_int_type.

The version of ignore in the primary template doesn't need a change,
because it doesn't use traits_type::find, instead characters are
extracted one-by-one and always matched using eq_int_type. That avoids
the inconsistency between find and eq_int_type.

libstdc++-v3/ChangeLog:

PR libstdc++/93672
* src/c++98/istream.cc (istream::ignore(streamsize, int_type)):
Treat all negative delimiter values as eof().
* testsuite/27_io/basic_istream/ignore/char/93672.cc: New test.
---
 libstdc++-v3/src/c++98/istream.cc |  5 -
 .../27_io/basic_istream/ignore/char/93672.cc  | 15 +++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc

diff --git a/libstdc++-v3/src/c++98/istream.cc 
b/libstdc++-v3/src/c++98/istream.cc
index 07ac739c26a..aa1069dea07 100644
--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -112,7 +112,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 basic_istream::
 ignore(streamsize __n, int_type __delim)
 {
-  if (traits_type::eq_int_type(__delim, traits_type::eof()))
+  // sgetc() returns either (int_type)(unsigned char)c or -1 for EOF.
+  // If __delim is negative, then eq_int_type(sgetc(), __delim) can only
+  // be true for EOF, so just treat all negative values as eof().
+  if (__delim < 0)
return ignore(__n);
 
   _M_gcount = 0;
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
new file mode 100644
index 000..6d11f5622c8
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
@@ -0,0 +1,15 @@
+// { dg-do run }
+
+#include 
+#include 
+
+int main()
+{
+  std::istringstream in("x\xfdxxx\xfex");
+  in.ignore(10, std::char_traits::to_int_type('\xfd'));
+  VERIFY( in.gcount() == 2 );
+  VERIFY( ! in.eof() );
+  in.ignore(10, '\xfe');
+  VERIFY( in.gcount() == 5 );
+  VERIFY( in.eof() );
+}
-- 
2.44.0



[committed] libstdc++: Reverse arguments in constraint for std::optional's <=> [PR104606]

2024-04-03 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk. Backports likely to follow.

-- >8 --

This is a workaround for a possible compiler bug that causes constraint
recursion in the operator<=>(const optional&, const U&) overload.

libstdc++-v3/ChangeLog:

PR libstdc++/104606
* include/std/optional (operator<=>(const optional&, const U&)):
Reverse order of three_way_comparable_with template arguments.
* testsuite/20_util/optional/relops/104606.cc: New test.
---
 libstdc++-v3/include/std/optional  |  2 +-
 .../20_util/optional/relops/104606.cc  | 18 ++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/optional/relops/104606.cc

diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 1e88e8b8880..3507c36a4d8 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -1430,7 +1430,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #ifdef __cpp_lib_three_way_comparison
   template
 requires (!__is_optional_v<_Up>)
-  && three_way_comparable_with<_Tp, _Up>
+  && three_way_comparable_with<_Up, _Tp>
 constexpr compare_three_way_result_t<_Tp, _Up>
 operator<=>(const optional<_Tp>& __x, const _Up& __v)
 { return bool(__x) ? *__x <=> __v : strong_ordering::less; }
diff --git a/libstdc++-v3/testsuite/20_util/optional/relops/104606.cc 
b/libstdc++-v3/testsuite/20_util/optional/relops/104606.cc
new file mode 100644
index 000..2b8df245219
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/optional/relops/104606.cc
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++17 } }
+
+// Bug 104606 comparison operator resolution with std::optional and -std=c++20
+
+#include 
+#include 
+#include 
+
+struct Value : std::variant> { };
+
+struct Comparator {
+  template  bool operator<=(const T &) { return true; }
+};
+
+std::optional o;
+Comparator c;
+
+auto x = c <= o;
-- 
2.44.0



[committed] libstdc++: Guard uses of char8_t with __cpp_char8_t [PR114519]

2024-04-02 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/114519
* include/bits/unicode.h (_Utf8_view): Guard with check for
char8_t being enabled.
(__literal_encoding_is_unicode): Guard use of char8_t with check
for it being enabled.
* testsuite/std/format/functions/114519.cc: New test.
---
 libstdc++-v3/include/bits/unicode.h   | 10 +++---
 libstdc++-v3/testsuite/std/format/functions/114519.cc |  3 +++
 2 files changed, 10 insertions(+), 3 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/functions/114519.cc

diff --git a/libstdc++-v3/include/bits/unicode.h 
b/libstdc++-v3/include/bits/unicode.h
index 51bf02e927f..0e95c86a0b0 100644
--- a/libstdc++-v3/include/bits/unicode.h
+++ b/libstdc++-v3/include/bits/unicode.h
@@ -578,8 +578,10 @@ namespace __unicode
   constexpr bool empty() const { return ranges::empty(_M_base); }
 };
 
+#ifdef __cpp_char8_t
   template
 using _Utf8_view = _Utf_view;
+#endif
   template
 using _Utf16_view = _Utf_view;
   template
@@ -991,12 +993,14 @@ inline namespace __v15_1_0
 consteval bool
 __literal_encoding_is_unicode()
 {
-  if constexpr (is_same_v<_CharT, char8_t>)
-   return true;
-  else if constexpr (is_same_v<_CharT, char16_t>)
+  if constexpr (is_same_v<_CharT, char16_t>)
return true;
   else if constexpr (is_same_v<_CharT, char32_t>)
  return true;
+#ifdef __cpp_char8_t
+  else if constexpr (is_same_v<_CharT, char8_t>)
+   return true;
+#endif
 
   const char* __enc = "";
 
diff --git a/libstdc++-v3/testsuite/std/format/functions/114519.cc 
b/libstdc++-v3/testsuite/std/format/functions/114519.cc
new file mode 100644
index 000..25a112a954e
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/format/functions/114519.cc
@@ -0,0 +1,3 @@
+// { dg-do compile { target c++20 } }
+// { dg-options "-fno-char8_t" }
+#include 
-- 
2.44.0



Re: [PATCH] libstdc++: Allow adjacent __maybe_present_t to overlap

2024-04-02 Thread Jonathan Wakely
On Tue, 2 Apr 2024 at 18:00, Pilar Latiesa wrote:
>
> Just out of curiosity: would this also work?
>
> template
> struct _Absent {};
>
> template
> using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, _Disc>>;
>
> That would avoid having to type 0, 1, ... manually.

This is subjectively horrible and, more objectively, would create
longer mangled names and additional RTTI.


Re: [PATCH] Fix up duplicated words mostly in comments, part 1

2024-04-02 Thread Jonathan Wakely
On Tue, 2 Apr 2024 at 08:47, Jakub Jelinek wrote:
>
> Hi!
>
> Like in r12-7519-g027e30414492d50feb2854aff38227b14300dc4b, I've done
> git grep -v 'long long\|optab optab\|template template\|double double' | grep 
> ' \([a-zA-Z]\+\) \1 '
>
> This is just part of the changes, mostly for non-gcc directories.
> I'll try to get to the rest soon.  Obviously, the above command also
> finds cases which are correct as is and shouldn't be changed, so one
> needs to manually inspect everything.
>
> I'd hope most of it is pretty obvious, but the config/ and libstdc++-v3/
> hunks include a tweak in a license wording, though other copies of the
> similar license have the wording right.

Those libstdc++ parts are fine, thanks.


>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2024-04-02  Jakub Jelinek  
>
> * Makefile.tpl: Fix duplicated words; returns returns ->
> returns.
> config/
> * lcmessage.m4: Fix duplicated words; can can -> can,
> package package -> package.
> libdecnumber/
> * decCommon.c (decFinalize): Fix duplicated words in
> comment; the the -> the.
> libgcc/
> * unwind-dw2-fde.c (struct fde_accumulator): Fix duplicated
> words in comment; is is -> is.
> libgfortran/
> * configure.host: Fix duplicated words; the the -> the.
> libgm2/
> * configure.host: Fix duplicated words; the the -> the.
> libgomp/
> * libgomp.texi (OpenMP 5.2): Fix duplicated words; with with ->
> with.
> (omp_target_associate_ptr): Fix duplicated words; either either ->
> either.
> (omp_init_allocator): Fix duplicated words; be be -> be.
> (omp_realloc): Fix duplicated words; is is -> is.
> (OMP_ALLOCATOR): Fix duplicated words; other other -> other.
> * priority_queue.h (priority_queue_multi_p): Fix duplicated words;
> to to -> to.
> libiberty/
> * regex.c (byte_re_match_2_internal): Fix duplicated words in comment;
> next next -> next.
> * dyn-string.c (dyn_string_init): Fix duplicated words in comment;
> of of -> of.
> libitm/
> * beginend.cc (GTM::gtm_thread::begin_transaction): Fix duplicated
> words in comment; not not -> not to.
> libobjc/
> * init.c (duplicate_classes): Fix duplicated words in comment; in in
> -> in.
> * sendmsg.c (__objc_prepare_dtable_for_class): Fix duplicated words
> in comment; the the -> the.
> * encoding.c (objc_layout_structure): Likewise.
> libstdc++-v3/
> * acinclude.m4: Fix duplicated words; file file -> file can.
> * configure.host: Fix duplicated words; the the -> the.
> libvtv/
> * vtv_rts.cc (vtv_fail): Fix duplicated words; to to -> to.
> * vtv_fail.cc (vtv_fail): Likewise.
>
> --- Makefile.tpl.jj 2024-01-10 12:19:07.609682386 +0100
> +++ Makefile.tpl2024-03-28 15:38:31.471917678 +0100
> @@ -1976,7 +1976,7 @@ configure-target-[+module+]: maybe-all-g
> (define dep-maybe (lambda ()
>(if (exist? "hard") "" "maybe-")))
>
> -   ;; dep-kind returns returns "prebootstrap" for configure or build
> +   ;; dep-kind returns "prebootstrap" for configure or build
> ;; dependencies of bootstrapped modules on a build module
> ;; (e.g. all-gcc on all-build-bison); "normal" if the dependency is
> ;; on an "install" target, or if the dependence module is not
> --- config/lcmessage.m4.jj  2020-01-11 16:31:53.155321678 +0100
> +++ config/lcmessage.m4 2024-03-28 16:01:40.879060037 +0100
> @@ -6,13 +6,13 @@ dnl Public License, this file may be dis
>  dnl that contains a configuration script generated by Autoconf, under
>  dnl the same distribution terms as the rest of that program.
>  dnl
> -dnl This file can can be used in projects which are not available under
> +dnl This file can be used in projects which are not available under
>  dnl the GNU General Public License or the GNU Library General Public
>  dnl License but which still want to provide support for the GNU gettext
>  dnl functionality.
>  dnl Please note that the actual code of the GNU gettext library is covered
>  dnl by the GNU Library General Public License, and the rest of the GNU
> -dnl gettext package package is covered by the GNU General Public License.
> +dnl gettext package is covered by the GNU General Public License.
>  dnl They are *not* in the public domain.
>
>  dnl Authors:
> --- libdecnumber/decCommon.c.jj 2024-01-03 12:07:28.096370943 +0100
> +++ libdecnumber/decCommon.c2024-03-28 16:00:26.576068973 +0100
> @@ -388,7 +388,7 @@ static decFloat * decFinalize(decFloat *
> UBFROMUI(ub-3, 0);   /* to  */
> }
>   /* [note ub could now be to left of msd, and it is not safe */
> - /* to write to the the left of the msd] */
> + /* to write to the left of the msd] */
>   /* now at most 3 digits left to non-9 (usually just the one) */

Re: [PATCH] libstdc++: Allow adjacent __maybe_present_t to overlap

2024-04-02 Thread Jonathan Wakely
On Mon, 1 Apr 2024 at 23:16, Patrick Palka  wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

This is a layout change for some specializations of slide_view, but
better to do that now than change it between gcc 14 and 15.

OK for trunk.


>
> -- >8 --
>
> Currently __maybe_present_t maps to the same empty class
> type independent of T.  This is suboptimal because it means adjacent
> __maybe_present_t members with the [[no_unique_address]]
> attribute can't overlap even if the conditionally present types are
> different.
>
> This patch fixes this by turning this empty class type into a template
> parameterized by the conditionally present type, so that
>
>   [[no_unique_address]] __maybe_present_t _M_a;
>   [[no_unique_address]] __maybe_present_t _M_b;
>
> now overlap if T and U are different.
>
> This patch goes a step further and also adds an optional integer
> discriminator parameter to allow for overlapping when T and U are
> the same.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (ranges::__detail::_Empty): Rename to ...
> (ranges::__detail::_Absent): ... this.  Turn into a template
> parameterized by the absent type _Tp and discriminator _Disc.
> (ranges::__detail::__maybe_present_t): Add an optional
> discriminator parameter.
> (slide_view::_M_cached_begin): Pass a discriminator argument to
> __maybe_present_t.
> (slide_view::_M_cached_end): Likewise.
> * testsuite/std/ranges/adaptors/sizeof.cc: Verify the size of
> slide_view is 3 instead 4 pointers.
> ---
>  libstdc++-v3/include/std/ranges | 13 -
>  .../testsuite/std/ranges/adaptors/sizeof.cc |  4 
>  2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 7d739852677..afce818376b 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -886,14 +886,17 @@ namespace views
>
>  namespace __detail
>  {
> -  struct _Empty { };
> +  template
> +struct _Absent { };
>
>// Alias for a type that is conditionally present
>// (and is an empty type otherwise).
>// Data members using this alias should use [[no_unique_address]] so that
>// they take no space when not needed.
> -  template
> -using __maybe_present_t = __conditional_t<_Present, _Tp, _Empty>;
> +  // The optional template parameter _Disc is for discriminating two 
> otherwise
> +  // equivalent absent types so that even they can overlap.
> +  template
> +using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, 
> _Disc>>;
>
>// Alias for a type that is conditionally const.
>template
> @@ -6553,10 +6556,10 @@ namespace views::__adaptor
>  range_difference_t<_Vp> _M_n;
>  [[no_unique_address]]
>__detail::__maybe_present_t<__detail::__slide_caches_first<_Vp>,
> - __detail::_CachedPosition<_Vp>> 
> _M_cached_begin;
> + __detail::_CachedPosition<_Vp>, 0> 
> _M_cached_begin;
>  [[no_unique_address]]
>__detail::__maybe_present_t<__detail::__slide_caches_last<_Vp>,
> - __detail::_CachedPosition<_Vp>> 
> _M_cached_end;
> + __detail::_CachedPosition<_Vp>, 1> 
> _M_cached_end;
>
>  template class _Iterator;
>  class _Sentinel;
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc 
> b/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
> index 12a9da3181d..08c01704d10 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
> @@ -49,3 +49,7 @@ static_assert(sizeof(ranges::lazy_split_view std::string_view>) == 4*ptr);
>
>  static_assert
>   (sizeof(ranges::reverse_view>) == 
> 3*ptr);
> +
> +#if __cpp_lib_ranges_slide
> +static_assert(sizeof(ranges::slide_view) == 3*ptr);
> +#endif
> --
> 2.44.0.448.gc2cbfbd2e2
>



Re: [PATCH] libstdc++: Add masked ++/-- implementation for sizeof < 16

2024-03-27 Thread Jonathan Wakely
On Wed, 27 Mar 2024 at 12:48, Matthias Kretz  wrote:
>
> And one more to fix follow-up / remaining failures. Tested on x86_64-linux-
> gnu.
>
> OK for trunk and 13?

OK for both, thanks.


>
>  8< --
>
> This resolves further failures (-Wreturn-type warnings) and test
> failures for where-* tests targeting AVX-512.
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd_x86.h (_S_masked_unary):
> Cast inputs < 16 bytes to 16 byte vectors before calling the
> right subtraction builtin. Before returning, truncate to the
> return vector type.
> ---
>  .../include/experimental/bits/simd_x86.h  | 24 +++
>  1 file changed, 14 insertions(+), 10 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──


Re: [PATCH v2] libstdc++: add ARM SVE support to std::experimental::simd

2024-03-27 Thread Jonathan Wakely
On Wed, 27 Mar 2024 at 12:13, Richard Sandiford
 wrote:
>
> Matthias Kretz  writes:
> > On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote:
> >> I'm still worried about:
> >>
> >>   #if _GLIBCXX_SIMD_HAVE_SVE
> >>   constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_BITS
> >> / 8; #else
> >>   constexpr inline int __sve_vectorized_size_bytes = 0;
> >>   #endif
> >>
> >> and the direct use __ARM_FEATURE_SVE_BITS elsewhere, for the reasons
> >> discussed here (including possible ODR problems):
> >>
> >>   https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640037.html
> >>   https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643734.html
> >>
> >> Logically the vector length should be a template parameter rather than
> >> an invariant.  Has this been resolved?  If not, it feels like a blocker
> >> to me (sorry).
> >
> > The vector length is always a template parameter to all user-facing API. 
> > Some
> > examples
> >
> > 1. on aarch64 the following is independent of SVE flags (and status quo):
> >
> >   simd is an alias for
> >   simd
> >
> >   fixed_size_simd is supposed to be ABI-stable anyway (passed via
> >   the stack, alignof == sizeof).
> >
> > 2. with -msve-vector-bits=512:
> >
> >   native_simd is an alias for
> >   simd>
> >
> >   simd> is an alias for
> >   simd>
> >
> > 3. with -msve-vector-bits=256:
> >
> >   native_simd is an alias for
> >   simd>
> >
> >   simd> is an alias for
> >   simd>
> >
> > Implementation functions are either [[gnu::always_inline]] or tagged with 
> > the
> > ABI tag type and the __odr_helper template argument (to ensure not-inlined
> > inline functions have unique names).
>
> Ah, thanks for the explanation.  I think the global native_float alias
> is problematic for reasons that you touched on in your later message.
> I'll reply more about that there.  But in other respects this looks good.
>
> > Does that make __ARM_FEATURE_SVE_BITS usage indirect enough?
>
> In principle, the only use of __ARM_FEATURE_SVE_BITS should be to determine
> the definition of native_simd (with the caveats above).  But current
> GCC restrictions might make that impractical.
>
> > Also for context, please consider that this is std::*experimental*::simd. 
> > The
> > underlying ISO document will likely get retracted at some point and the 
> > whole
> > API and implementation (hopefully) superseded by C++26. The main purpose of
> > the spec and implementation is to gather experience.
>
> Ah, ok.  If this is a deliberate experiment for evidence-gathering
> purposes, rather than a long-term commitment, then I agree the barrier
> should be lower.

Yes, that's definitely what this code is for. The more feedback and
impl-experience we can get now with the std::experimental::simd
version, the better std::simd will be when that happens.

In practice, we probably won't ever actually remove the
 header even when the experiment is over (e.g. we
still have  with std::tr1::shared_ptr!), but we are likely
to consider it unmaintained and deprecated once it's superseded by
std::simd.

> So yeah, I'll withdraw my objection.  I've no problem with this going
> into GCC 14 on the basis above.  Thanks again to you and Srinivas for
> working on this.
>
> Richard
>



Re: [PATCH v2] libstdc++: add ARM SVE support to std::experimental::simd

2024-03-27 Thread Jonathan Wakely
On Fri, 8 Mar 2024 at 09:58, Matthias Kretz wrote:
>
> Hi,
>
> I applied and did extended testing on x86_64 (no regressions) and aarch64
> using qemu testing SVE 256, 512, and 1024. Looks good!
>
> While going through the applied patch I noticed a few style issues that I
> simply turned into a patch (attached).
>
[...]
>
> From my side, with the noted changes the patch is ready for merging.
> @Jonathan, any chance for a green light before GCC 14.1?

As discussed on IRC, please push the revised patch with your
suggestions incorporated (and post to the lists for posterity).

Thanks, everybody, for the patches and the thorough review.



Re: [PATCH] libstdc++: Fix call signature of builtins from masked ++/--

2024-03-27 Thread Jonathan Wakely
On Wed, 27 Mar 2024 at 08:51, Matthias Kretz  wrote:
>
> This is broken on GCC 13 and 14 (https://compiler-explorer.com/z/GPKGPGs6T)
>
> Tested on x86_64-linux-gnu.
>
> OK for trunk and 13?

OK for both, thanks.


>
> --- 8< -
>
> This resolves failures in the "expensive" where-* test of check-simd
> when targeting AVX-512.
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd_x86.h (_S_masked_unary): Call
> the 4- and 8-byte variants of __builtin_ia32_subp[ds] without
> rounding direction argument.
> ---
>  libstdc++-v3/include/experimental/bits/simd_x86.h | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──


Re: [PATCH 1/2] libstdc++: Add dg-require-cpp-feature-test to test feature test macros

2024-03-26 Thread Jonathan Wakely
Pushed to trunk.

On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely  wrote:
>
> Thoughts? There are only a few uses for this presently, but I can see it
> being useful often in future. The library exposes which features it
> supports in a standardized way, so we can use those in tests to skip
> tests for features that aren't available on all targets.
>
> The obvious downside is that it becomes harder to notice if a particular
> feature is missing on all targets, because we don't get FAILs we just
> skip all tests as UNSUPPORTED. And the checks for whether 
> correctly defines the macro become redundant, because the test won't
> even get run if it doesn't. But we won't use this dg-require for many
> tests, only the ones where support is target-dependent because it relies
> on something non-standard or not available on all targets (like
> nl_langinfo_l or libbacktrace).
>
> -- >8 -
>
> This adds a new dejagnu directive which can be used to make a test
> depend on a feature test macro such as __cpp_lib_text_encoding. This is
> mroe flexible than writing a new dg-require-xxx for each feature.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/lib/dg-options.exp (dg-require-cpp-feature-test):
> New proc.
> * testsuite/lib/libstdc++.exp (check_v3_target_cpp_feature_test):
> New proc.
> * testsuite/std/text_encoding/cons.cc: Use new directive to skip
> the test if the __cpp_lib_text_encoding feature test macro is
> not defined.
> * testsuite/std/text_encoding/requirements.cc: Likewise.
> ---
>  libstdc++-v3/testsuite/lib/dg-options.exp |  9 +
>  libstdc++-v3/testsuite/lib/libstdc++.exp  | 15 +++
>  libstdc++-v3/testsuite/std/text_encoding/cons.cc  |  1 +
>  .../testsuite/std/text_encoding/requirements.cc   |  3 ++-
>  4 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
> b/libstdc++-v3/testsuite/lib/dg-options.exp
> index 00ca678a53a..802bfc0b492 100644
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -277,6 +277,15 @@ proc dg-require-target-fs-lwt { args } {
>  return
>  }
>
> +proc dg-require-cpp-feature-test { n args } {
> +if { ![ check_v3_target_cpp_feature_test $args ] } {
> +   upvar dg-do-what dg-do-what
> +   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
> +   return
> +}
> +return
> +}
> +
>  proc add_options_for_no_pch { flags } {
>  # Remove any inclusion of bits/stdc++.h from the options.
>  regsub -all -- "-include bits/stdc...h" $flags "" flags
> diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
> b/libstdc++-v3/testsuite/lib/libstdc++.exp
> index 7466fb51c58..2b31c950826 100644
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -1134,6 +1134,21 @@ proc v3_check_preprocessor_condition { name cond { inc 
> "" } } {
>  return [v3_try_preprocess name $code $flags]
>  }
>
> +# Return 1 if libstdc++ defines macro for the current target, 0 otherwise.
> +proc check_v3_target_cpp_feature_test { cond } {
> +global cxxflags
> +set cxxflags_saved $cxxflags
> +# Use the latest standard, so that all feature test macros are defined.
> +# We need to do it here, because this check happens before v3-dg-runtest
> +# runs its loop to test multiple times with different -std options.
> +# This should be updated when a new -std is added.
> +set cxxflags "$cxxflags -std=gnu++26"
> +set inc "#include "
> +set result [v3_check_preprocessor_condition cpp_feature_test "$cond" 
> $inc]
> +set cxxflags $cxxflags_saved
> +return $result
> +}
> +
>  # Return 1 if Debug Mode is active, 0 otherwise.
>  proc check_v3_target_debug_mode { } {
>  global cxxflags
> diff --git a/libstdc++-v3/testsuite/std/text_encoding/cons.cc 
> b/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> index 8fcc2ec8c3b..4196e32ea8b 100644
> --- a/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> +++ b/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> @@ -1,4 +1,5 @@
>  // { dg-do run { target c++26 } }
> +// { dg-require-cpp-feature-test "__cpp_lib_text_encoding" }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc 
> b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> index a1d5d6baee1..3889b250688 100644
> --- a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> +++ b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> @@ -1,4 +1,5 @@
>  // { dg-do compile { target c++26 } }
> +// { dg-require-cpp-feature-test __cpp_lib_text_encoding }
>  // { dg-add-options no_pch }
>
>  #include 
>



Re: [PATCH 2/2] libstdc++: Replace stacktrace effective target with feature test

2024-03-26 Thread Jonathan Wakely
Pushed to trunk.

On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely  wrote:
>
> And this replaces an existing custom dg-require- directive with a use of
> the new one that checks for a standard feature test macro. I didn't see
> any other existing dg-require-xxx directives that can be replaced like
> this.
>
> -- >8 --
>
> Remove the dejagnu code for checking whether std::stacktrace is supported
> and just use the new dg-require-cpp-feature-test directive to check for
> __cpp_lib_stacktrace instead.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/19_diagnostics/stacktrace/current.cc: Check for
> __cpp_lib_stacktrace instead of check for stacktrace ET.
> * testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/hash.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/output.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/synopsis.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/version.cc: Likewise.
> * testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
> Likewise.
> * testsuite/lib/libstdc++.exp (check_effective_target_stacktrace):
> Remove.
> ---
>  .../testsuite/19_diagnostics/stacktrace/current.cc| 2 +-
>  libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc | 2 +-
>  libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc  | 2 +-
>  .../testsuite/19_diagnostics/stacktrace/output.cc | 2 +-
>  .../testsuite/19_diagnostics/stacktrace/stacktrace.cc | 2 +-
>  .../testsuite/19_diagnostics/stacktrace/synopsis.cc   | 2 +-
>  .../testsuite/19_diagnostics/stacktrace/version.cc| 2 +-
>  .../23_containers/vector/debug/assign4_backtrace_neg.cc   | 2 +-
>  libstdc++-v3/testsuite/lib/libstdc++.exp  | 8 
>  9 files changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc 
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> index a27836d27af..b1af5f74fb2 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> @@ -1,6 +1,6 @@
>  // { dg-options "-lstdc++exp" }
>  // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc 
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> index ab016d56400..bb348ebef8f 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> @@ -1,6 +1,6 @@
>  // { dg-options "-lstdc++exp" }
>  // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
>  #include 
>  #include "testsuite_hooks.h"
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc 
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> index 21705098ff0..2176596ae5c 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> @@ -1,6 +1,6 @@
>  // { dg-options "-lstdc++exp" }
>  // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc 
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> index 67f1e0cebaf..e27aea1f508 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> @@ -1,6 +1,6 @@
>  // { dg-options "-lstdc++exp" }
>  // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>  // { dg-add-options no_pch }
>
>  #include 
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc 
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> index 5dfa76951df..070c4157471 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> @@ -1,6 +1,6 @@
>  // { dg-options "-lstdc++exp" }
>  // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-featu

Re: [PATCH 1/2] libstdc++: fix _V badname in

2024-03-26 Thread Jonathan Wakely
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator: Fix _V badname.

OK for trunk, thanks.


> ---
>  libstdc++-v3/include/std/generator | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/generator 
> b/libstdc++-v3/include/std/generator
> index 87983ee5e7c6..2d1dcced1e57 100644
> --- a/libstdc++-v3/include/std/generator
> +++ b/libstdc++-v3/include/std/generator
> @@ -76,14 +76,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> * @headerfile generator
> * @since C++23
> */
> -  template
> +  template
>  class generator;
>
>/// @cond undocumented
>namespace __gen
>{
>  /// _Reference type for a generator whose reference (first argument) and
> -/// value (second argument) types are _Ref and _V.
> +/// value (second argument) types are _Ref and _Val.
>  template
>  using _Reference_t = __conditional_t,
>  _Ref&&, _Ref>;
> @@ -642,14 +642,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>} // namespace __gen
>/// @endcond
>
> -  template
> +  template
>  class generator
> -  : public ranges::view_interface>
> +  : public ranges::view_interface>
>  {
> -  using _Value = __conditional_t, remove_cvref_t<_Ref>, 
> _V>;
> +  using _Value = __conditional_t,
> +remove_cvref_t<_Ref>,
> +_Val>;
>static_assert(__gen::_Cv_unqualified_object<_Value>,
> "Generator value must be a cv-unqualified object type");
> -  using _Reference = __gen::_Reference_t<_Ref, _V>;
> +  using _Reference = __gen::_Reference_t<_Ref, _Val>;
>static_assert(is_reference_v<_Reference>
> || (__gen::_Cv_unqualified_object<_Reference>
> && copy_constructible<_Reference>),
> @@ -737,8 +739,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>bool _M_began = false;
>  };
>
> -  template
> -struct generator<_Ref, _V, _Alloc>::_Iterator
> +  template
> +struct generator<_Ref, _Val, _Alloc>::_Iterator
>  {
>using value_type = _Value;
>using difference_type = ptrdiff_t;
> --
> 2.44.0
>



Re: [PATCH 2/2] libstdc++: fix generator iterator operator* return type

2024-03-26 Thread Jonathan Wakely
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović  wrote:
>
> Per the standard, the return type of a generators ranges iterator op*
> should be the reference type rather than the yielded type.
>
> The yielded type was used here by mistake.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator (generator::_Iterator::operator*): Fix
> return type.
> * testsuite/24_iterators/range_generators/iter_deref_return.cc:
> New test.
> ---
>  libstdc++-v3/include/std/generator|  4 +--
>  .../range_generators/iter_deref_return.cc | 34 +++
>  2 files changed, 36 insertions(+), 2 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
>
> diff --git a/libstdc++-v3/include/std/generator 
> b/libstdc++-v3/include/std/generator
> index 2d1dcced1e57..789016b5a883 100644
> --- a/libstdc++-v3/include/std/generator
> +++ b/libstdc++-v3/include/std/generator
> @@ -773,12 +773,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>operator++(int)
>{ this->operator++(); }
>
> -  yielded
> +  _Reference
>operator*()
> const noexcept(is_nothrow_move_constructible_v<_Reference>)
>{
> auto& __p = this->_M_coro.promise();
> -   return static_cast(*__p._M_value());
> +   return static_cast<_Reference>(*__p._M_value());
>}
>
>  private:
> diff --git 
> a/libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc 
> b/libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
> new file mode 100644
> index ..7bdbf4d489ec
> --- /dev/null
> +++ 
> b/libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
> @@ -0,0 +1,34 @@
> +// { dg-do compile { target c++23 } }
> +// Copyright (C) 2023-2024 Free Software Foundation, Inc.

Just 2024 here.

> +//
> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.
> +
> +// Under Section 7 of GPL version 3, you are granted additional
> +// permissions described in the GCC Runtime Library Exception, version
> +// 3.1, as published by the Free Software Foundation.
> +
> +// You should have received a copy of the GNU General Public License and
> +// a copy of the GCC Runtime Library Exception along with this program;
> +// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +// .


I don't think we want the last two paragraphs about the runtime
exception. That's relevant to code being compiled into the users
binary as inline functions or templates, which doesn't matter for
testcases.

I see we have 10 existing tests that use the runtime exception text,
which I'll fix. For comparison, there are 9000 tests with the GPL
text, so the vast majority don't have the exception.

OK for trunk with the copyright date fixed and the exception text
dropped, thanks.

> +
> +#include 
> +
> +// Check that the return type of iterator::operator* is the reference type.
> +// Pre-op* return type fix, this'd have resulted in a op* return type of 
> const
> +// bool&.
> +
> +std::generator
> +foo();
> +
> +static_assert(std::is_same_v);
> +static_assert(std::is_same_v bool&>);
> --
> 2.44.0
>



[committed] libstdc++: Fix incorrect macro used in #undef in test

2024-03-25 Thread Jonathan Wakely
Tested aarch64-linux. Puhed to trunk.

-- >8 --

This was a copy & paste error.

libstdc++-v3/ChangeLog:

* testsuite/std/text_encoding/requirements.cc: #undef the
correct macro.
---
 libstdc++-v3/testsuite/std/text_encoding/requirements.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc 
b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
index a1d5d6baee1..6cd71b68225 100644
--- a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
+++ b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
@@ -8,7 +8,7 @@
 # error "Feature-test macro for text_encoding has wrong value in 
"
 #endif
 
-#undef __cpp_lib_expected
+#undef __cpp_lib_text_encoding
 #include 
 #ifndef __cpp_lib_text_encoding
 # error "Feature-test macro for text_encoding missing in "
-- 
2.44.0



[committed] libstdc++: Disable std::formatter specializations (LWG 3944)

2024-03-23 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

This was just approved in Tokyo as a DR for C++23. It doesn't affect us
yet, because we don't implement the __cpp_lib_format_ranges features. We
can add the disabled specializations and add a testcase now though.

libstdc++-v3/ChangeLog:

* include/std/format (formatter): Disable specializations that
would allow sequences of narrow characters to be formatted as
wchar_t without conversion, as per LWG 3944.
* testsuite/std/format/formatter/lwg3944.cc: New test.
---
 libstdc++-v3/include/std/format   | 23 ++
 .../testsuite/std/format/formatter/lwg3944.cc | 31 +++
 2 files changed, 54 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index 613016d1a10..22dcb5f24bd 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -2478,6 +2478,29 @@ namespace __format
 };
   /// @}
 
+#if defined _GLIBCXX_USE_WCHAR_T && __cpp_lib_format_ranges
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3944. Formatters converting sequences of char to sequences of wchar_t
+
+  namespace __format { struct __disabled; }
+
+  // std::formatter<__disabled, C> uses the primary template, which is 
disabled.
+  template<>
+struct formatter
+: private formatter<__format::__disabled, wchar_t> { };
+  template<>
+struct formatter
+: private formatter<__format::__disabled, wchar_t> { };
+  template
+struct formatter
+: private formatter<__format::__disabled, wchar_t> { };
+  template
+struct formatter, wchar_t>
+: private formatter<__format::__disabled, wchar_t> { };
+  template
+struct formatter, wchar_t>
+: private formatter<__format::__disabled, wchar_t> { };
+#endif
 
 /// @cond undocumented
 namespace __format
diff --git a/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc 
b/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
new file mode 100644
index 000..ff5f075bcc8
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/format/formatter/lwg3944.cc
@@ -0,0 +1,31 @@
+// { dg-do compile { target c++20 } }
+// { dg-options "-Wno-unused-result" }
+
+// LWG 3944. Formatters converting sequences of char to sequences of wchar_t
+
+#include 
+
+void test_lwg3944()
+{
+  // Ill-formed in C++20 and C++23
+  const char* cstr = "hello";
+  char* str = const_cast(cstr);
+  std::format(L"{}", str); // { dg-error "here" }
+  std::format(L"{}",cstr); // { dg-error "here" }
+
+  // Ill-formed in C++20
+  // In C++23 they give L"['h', 'e', 'l', 'l', 'o']"
+  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 __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
+}
+
+// { dg-error "std::formatter must be specialized" "" { target *-*-* } 0 }
+// { dg-prune-output "use of deleted function" }
+// { dg-prune-output "no matching function" }
+// { dg-prune-output "has no member named 'parse'" }
+// { dg-prune-output "not a constant expression" }
-- 
2.44.0



[committed] libstdc++: Add __is_in_place_index_v helper and use it in

2024-03-23 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

We already have __is_in_place_type_v for in_place_type_t so adding an
equivalent for in_place_index_t allows us avoid a class template
instantiation for the __not_in_place_tag constraint on the most
commonly-used std::variant::variant(T&&) constructor.

For in_place_type_t we also have a __is_in_place_type class template
defined in terms of the variable template, but that isn't actually used
anywhere. I'm not adding an equivalent for the new variable template,
because that wouldn't be used either.

For GCC 15 we should remove the unused __is_in_place_tag and
__is_in_place_type class templates.

libstdc++-v3/ChangeLog:

* include/bits/utility.h (__is_in_place_index_v): New variable
template.
* include/std/variant (__not_in_place_tag): Define in terms of
variable templates not a class template.
---
 libstdc++-v3/include/bits/utility.h | 6 ++
 libstdc++-v3/include/std/variant| 3 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/utility.h 
b/libstdc++-v3/include/bits/utility.h
index 2a741bf7000..9f3b99231b3 100644
--- a/libstdc++-v3/include/bits/utility.h
+++ b/libstdc++-v3/include/bits/utility.h
@@ -223,6 +223,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 using __is_in_place_type = bool_constant<__is_in_place_type_v<_Tp>>;
 
+  template
+inline constexpr bool __is_in_place_index_v = false;
+
+  template
+inline constexpr bool __is_in_place_index_v> = true;
+
 #endif // C++17
 
 #if _GLIBCXX_USE_BUILTIN_TRAIT(__type_pack_element)
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 4b9002e0917..f79d95db7a8 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1414,7 +1414,8 @@ namespace __variant
 
   template
static constexpr bool __not_in_place_tag
- = !__is_in_place_tag<__remove_cvref_t<_Tp>>::value;
+ = !__is_in_place_type_v<__remove_cvref_t<_Tp>>
+ && !__is_in_place_index_v<__remove_cvref_t<_Tp>>;
 
 public:
 #if __cpp_concepts
-- 
2.44.0



[committed] libstdc++: Use std::type_identity_t in as per LWG 3950 [PR114400]

2024-03-23 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

The difference between __type_identity_t and std::type_identity_t is
observable, as demonstrated in the PR. Nobody in LWG seems to think this
an example we should really care about, but it seems easy and harmless
to change this.

libstdc++-v3/ChangeLog:

PR libstdc++/114400
* include/std/string_view (operator==): Use std::type_identity_t
in C++20 instead of our own __type_identity_t.
---
 libstdc++-v3/include/std/string_view | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/string_view 
b/libstdc++-v3/include/std/string_view
index e30a9c1768e..a7c5a126461 100644
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -602,15 +602,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // deduction and the other argument gets implicitly converted to the deduced
   // type (see N3766).
 
+#if __cpp_lib_three_way_comparison
   template
 [[nodiscard]]
 constexpr bool
 operator==(basic_string_view<_CharT, _Traits> __x,
-   __type_identity_t> __y)
+  type_identity_t> __y)
 noexcept
 { return __x.size() == __y.size() && __x.compare(__y) == 0; }
 
-#if __cpp_lib_three_way_comparison
   template
 [[nodiscard]]
 constexpr auto
@@ -620,6 +620,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 -> decltype(__detail::__char_traits_cmp_cat<_Traits>(0))
 { return __detail::__char_traits_cmp_cat<_Traits>(__x.compare(__y)); }
 #else
+  template
+[[nodiscard]]
+constexpr bool
+operator==(basic_string_view<_CharT, _Traits> __x,
+  __type_identity_t> __y)
+noexcept
+{ return __x.size() == __y.size() && __x.compare(__y) == 0; }
+
   template
 [[nodiscard]]
 constexpr bool
-- 
2.44.0



[PATCH 2/2] libstdc++: Replace stacktrace effective target with feature test

2024-03-22 Thread Jonathan Wakely
And this replaces an existing custom dg-require- directive with a use of
the new one that checks for a standard feature test macro. I didn't see
any other existing dg-require-xxx directives that can be replaced like
this.

-- >8 --

Remove the dejagnu code for checking whether std::stacktrace is supported
and just use the new dg-require-cpp-feature-test directive to check for
__cpp_lib_stacktrace instead.

libstdc++-v3/ChangeLog:

* testsuite/19_diagnostics/stacktrace/current.cc: Check for
__cpp_lib_stacktrace instead of check for stacktrace ET.
* testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/hash.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/output.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/synopsis.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/version.cc: Likewise.
* testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
Likewise.
* testsuite/lib/libstdc++.exp (check_effective_target_stacktrace):
Remove.
---
 .../testsuite/19_diagnostics/stacktrace/current.cc| 2 +-
 libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc | 2 +-
 libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc  | 2 +-
 .../testsuite/19_diagnostics/stacktrace/output.cc | 2 +-
 .../testsuite/19_diagnostics/stacktrace/stacktrace.cc | 2 +-
 .../testsuite/19_diagnostics/stacktrace/synopsis.cc   | 2 +-
 .../testsuite/19_diagnostics/stacktrace/version.cc| 2 +-
 .../23_containers/vector/debug/assign4_backtrace_neg.cc   | 2 +-
 libstdc++-v3/testsuite/lib/libstdc++.exp  | 8 
 9 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc 
b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
index a27836d27af..b1af5f74fb2 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
@@ -1,6 +1,6 @@
 // { dg-options "-lstdc++exp" }
 // { dg-do run { target c++23 } }
-// { dg-require-effective-target stacktrace }
+// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc 
b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
index ab016d56400..bb348ebef8f 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
@@ -1,6 +1,6 @@
 // { dg-options "-lstdc++exp" }
 // { dg-do run { target c++23 } }
-// { dg-require-effective-target stacktrace }
+// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
 
 #include 
 #include "testsuite_hooks.h"
diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc 
b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
index 21705098ff0..2176596ae5c 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
@@ -1,6 +1,6 @@
 // { dg-options "-lstdc++exp" }
 // { dg-do run { target c++23 } }
-// { dg-require-effective-target stacktrace }
+// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc 
b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
index 67f1e0cebaf..e27aea1f508 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
@@ -1,6 +1,6 @@
 // { dg-options "-lstdc++exp" }
 // { dg-do run { target c++23 } }
-// { dg-require-effective-target stacktrace }
+// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
 // { dg-add-options no_pch }
 
 #include 
diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc 
b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
index 5dfa76951df..070c4157471 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
@@ -1,6 +1,6 @@
 // { dg-options "-lstdc++exp" }
 // { dg-do run { target c++23 } }
-// { dg-require-effective-target stacktrace }
+// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
 
 #include 
 #include "testsuite_allocator.h"
diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc 
b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc
index 9e775b86ac9..b99d382ec26 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc
@@ -1,5 +1,5 @@
 // { dg-do compile { target c++23 } }
-// { dg-require-effective-target stacktrace }
+// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
 // { dg-require-normal-namespace "" }
 // { dg-add-options no_pch }
 
diff 

[PATCH 1/2] libstdc++: Add dg-require-cpp-feature-test to test feature test macros

2024-03-22 Thread Jonathan Wakely
Thoughts? There are only a few uses for this presently, but I can see it
being useful often in future. The library exposes which features it
supports in a standardized way, so we can use those in tests to skip
tests for features that aren't available on all targets.

The obvious downside is that it becomes harder to notice if a particular
feature is missing on all targets, because we don't get FAILs we just
skip all tests as UNSUPPORTED. And the checks for whether 
correctly defines the macro become redundant, because the test won't
even get run if it doesn't. But we won't use this dg-require for many
tests, only the ones where support is target-dependent because it relies
on something non-standard or not available on all targets (like
nl_langinfo_l or libbacktrace).

-- >8 -

This adds a new dejagnu directive which can be used to make a test
depend on a feature test macro such as __cpp_lib_text_encoding. This is
mroe flexible than writing a new dg-require-xxx for each feature.

libstdc++-v3/ChangeLog:

* testsuite/lib/dg-options.exp (dg-require-cpp-feature-test):
New proc.
* testsuite/lib/libstdc++.exp (check_v3_target_cpp_feature_test):
New proc.
* testsuite/std/text_encoding/cons.cc: Use new directive to skip
the test if the __cpp_lib_text_encoding feature test macro is
not defined.
* testsuite/std/text_encoding/requirements.cc: Likewise.
---
 libstdc++-v3/testsuite/lib/dg-options.exp |  9 +
 libstdc++-v3/testsuite/lib/libstdc++.exp  | 15 +++
 libstdc++-v3/testsuite/std/text_encoding/cons.cc  |  1 +
 .../testsuite/std/text_encoding/requirements.cc   |  3 ++-
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index 00ca678a53a..802bfc0b492 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -277,6 +277,15 @@ proc dg-require-target-fs-lwt { args } {
 return
 }
 
+proc dg-require-cpp-feature-test { n args } {
+if { ![ check_v3_target_cpp_feature_test $args ] } {
+   upvar dg-do-what dg-do-what
+   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+   return
+}
+return
+}
+
 proc add_options_for_no_pch { flags } {
 # Remove any inclusion of bits/stdc++.h from the options.
 regsub -all -- "-include bits/stdc...h" $flags "" flags
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 7466fb51c58..2b31c950826 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1134,6 +1134,21 @@ proc v3_check_preprocessor_condition { name cond { inc 
"" } } {
 return [v3_try_preprocess name $code $flags]
 }
 
+# Return 1 if libstdc++ defines macro for the current target, 0 otherwise.
+proc check_v3_target_cpp_feature_test { cond } {
+global cxxflags
+set cxxflags_saved $cxxflags
+# Use the latest standard, so that all feature test macros are defined.
+# We need to do it here, because this check happens before v3-dg-runtest
+# runs its loop to test multiple times with different -std options.
+# This should be updated when a new -std is added.
+set cxxflags "$cxxflags -std=gnu++26"
+set inc "#include "
+set result [v3_check_preprocessor_condition cpp_feature_test "$cond" $inc]
+set cxxflags $cxxflags_saved
+return $result
+}
+
 # Return 1 if Debug Mode is active, 0 otherwise.
 proc check_v3_target_debug_mode { } {
 global cxxflags
diff --git a/libstdc++-v3/testsuite/std/text_encoding/cons.cc 
b/libstdc++-v3/testsuite/std/text_encoding/cons.cc
index 8fcc2ec8c3b..4196e32ea8b 100644
--- a/libstdc++-v3/testsuite/std/text_encoding/cons.cc
+++ b/libstdc++-v3/testsuite/std/text_encoding/cons.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++26 } }
+// { dg-require-cpp-feature-test "__cpp_lib_text_encoding" }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc 
b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
index a1d5d6baee1..3889b250688 100644
--- a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
+++ b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++26 } }
+// { dg-require-cpp-feature-test __cpp_lib_text_encoding }
 // { dg-add-options no_pch }
 
 #include 



[committed] libstdc++: Destroy allocators in re-inserted container nodes [PR114401]

2024-03-22 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

This should be backported to all branches, as the failure to destroy the
allocators in the re-inserted nodes results in potential resource leaks.

-- >8 --

The allocator objects in container node handles were not being destroyed
after the node was re-inserted into a container. They are stored in a
union and so need to be explicitly destroyed when the node becomes
empty. The containers were zeroing the node handle's pointer, which
makes it empty, causing the handle's destructor to think there's nothign
to clean up.

Add a new member function to the node handle which destroys the
allocator and zeros the pointer. Change the containers to call that
instead of just changing the pointer manually.

We can also remove the _M_empty member of the union which is not
necessary.

libstdc++-v3/ChangeLog:

PR libstdc++/114401
* include/bits/hashtable.h (_Hashtable::_M_reinsert_node): Call
release() on node handle instead of just zeroing its pointer.
(_Hashtable::_M_reinsert_node_multi): Likewise.
(_Hashtable::_M_merge_unique): Likewise.
(_Hashtable::_M_merge_multi): Likewise.
* include/bits/node_handle.h (_Node_handle_common::release()):
New member function.
(_Node_handle_common::_Optional_alloc::_M_empty): Remove
unnecessary union member.
(_Node_handle_common): Declare _Hashtable as a friend.
* include/bits/stl_tree.h (_Rb_tree::_M_reinsert_node_unique):
Call release() on node handle instead of just zeroing its
pointer.
(_Rb_tree::_M_reinsert_node_equal): Likewise.
(_Rb_tree::_M_reinsert_node_hint_unique): Likewise.
(_Rb_tree::_M_reinsert_node_hint_equal): Likewise.
* testsuite/23_containers/multiset/modifiers/114401.cc: New test.
* testsuite/23_containers/set/modifiers/114401.cc: New test.
* testsuite/23_containers/unordered_multiset/modifiers/114401.cc: New 
test.
* testsuite/23_containers/unordered_set/modifiers/114401.cc: New test.
---
 libstdc++-v3/include/bits/hashtable.h |  12 +-
 libstdc++-v3/include/bits/node_handle.h   |  19 ++-
 libstdc++-v3/include/bits/stl_tree.h  |  12 +-
 .../multiset/modifiers/114401.cc  | 125 +
 .../23_containers/set/modifiers/114401.cc | 125 +
 .../unordered_multiset/modifiers/114401.cc| 126 ++
 .../unordered_set/modifiers/114401.cc | 126 ++
 7 files changed, 530 insertions(+), 15 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/23_containers/multiset/modifiers/114401.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/set/modifiers/114401.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/unordered_multiset/modifiers/114401.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/114401.cc

diff --git a/libstdc++-v3/include/bits/hashtable.h 
b/libstdc++-v3/include/bits/hashtable.h
index c3ef7a0a3d5..cd3e1ac297c 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -1036,7 +1036,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // DR 1189.
   // reserve, if present, comes from _Rehash_base.
 
-#if __cplusplus > 201402L
+#if __glibcxx_node_extract // >= C++17
   /// Re-insert an extracted node into a container with unique keys.
   insert_return_type
   _M_reinsert_node(node_type&& __nh)
@@ -1078,7 +1078,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  {
__ret.position
  = _M_insert_unique_node(__bkt, __code, __nh._M_ptr);
-   __nh._M_ptr = nullptr;
+   __nh.release();
__ret.inserted = true;
  }
  }
@@ -1098,7 +1098,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
auto __code = this->_M_hash_code(__k);
auto __ret
  = _M_insert_multi_node(__hint._M_cur, __code, __nh._M_ptr);
-   __nh._M_ptr = nullptr;
+   __nh.release();
return __ret;
   }
 
@@ -1200,7 +1200,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  auto __nh = __src.extract(__pos);
  _M_insert_unique_node(__bkt, __code, __nh._M_ptr, __n_elt);
- __nh._M_ptr = nullptr;
+ __nh.release();
  __n_elt = 1;
}
  else if (__n_elt != 1)
@@ -1227,10 +1227,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
= _M_src_hash_code(__src.hash_function(), __k, *__pos._M_cur);
  auto __nh = __src.extract(__pos);
  __hint = _M_insert_multi_node(__hint, __code, __nh._M_ptr)._M_cur;
- __nh._M_ptr = nullptr;
+ __nh.release();
}
}
-#endif // C++17
+#endif // C++17 __glibcxx_node_extract
 
 private:
   // Helper rehash method used when keys are unique.
diff --git a/libstdc++-v3/include/bits/node_handle.h 

Re: [PATCH] libstdc++: Constrain std::vector default constructor [PR113841]

2024-03-22 Thread Jonathan Wakely
Pushed to trunk. Backport to gcc-13 needed too, as the changes to use
concepts for std::pair constructors are on that branch.

On Tue, 19 Mar 2024 at 15:59, Jonathan Wakely  wrote:
>
> This fixes the problem in the PR, which is revealed by the new
> concept-based constraints on std::pair constructors in C++20 mode. That
> makes this a C++20 regression, as the PR's example compiles with C++17.
>
> We need something similar for std::basic_string too, which I'll do
> later.
>
> Any comments?
>
> Tested aarch64-linux.
>
> -- >8 --
>
> This is needed to avoid errors outside the immediate context when
> evaluating is_default_constructible_v> when A is not
> default constructible.
>
> To avoid diagnostic regressions for 23_containers/vector/48101_neg.cc we
> need to make the std::allocator partial specializations default
> constructible, which they probably should have been anyway.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/113841
> * include/bits/allocator.h (allocator): Add default
> constructor to partial specializations for cv-qualified types.
> * include/bits/stl_vector.h (_Vector_impl::_Vector_impl()):
> Constrain so that it's only present if the allocator is default
> constructible.
> * include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()):
> Likewise.
> * testsuite/23_containers/vector/cons/113841.cc: New test.
> ---
>  libstdc++-v3/include/bits/allocator.h |  3 ++
>  libstdc++-v3/include/bits/stl_bvector.h   |  3 ++
>  libstdc++-v3/include/bits/stl_vector.h|  3 ++
>  .../23_containers/vector/cons/113841.cc   | 34 +++
>  4 files changed, 43 insertions(+)
>  create mode 100644 libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc
>
> diff --git a/libstdc++-v3/include/bits/allocator.h 
> b/libstdc++-v3/include/bits/allocator.h
> index ff4f5b9137b..9e75b37fce7 100644
> --- a/libstdc++-v3/include/bits/allocator.h
> +++ b/libstdc++-v3/include/bits/allocator.h
> @@ -254,6 +254,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  {
>  public:
>typedef _Tp value_type;
> +  allocator() { }
>template allocator(const allocator<_Up>&) { }
>  };
>
> @@ -262,6 +263,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  {
>  public:
>typedef _Tp value_type;
> +  allocator() { }
>template allocator(const allocator<_Up>&) { }
>  };
>
> @@ -270,6 +272,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  {
>  public:
>typedef _Tp value_type;
> +  allocator() { }
>template allocator(const allocator<_Up>&) { }
>  };
>/// @endcond
> diff --git a/libstdc++-v3/include/bits/stl_bvector.h 
> b/libstdc++-v3/include/bits/stl_bvector.h
> index a3343d95b36..d567e26f4e4 100644
> --- a/libstdc++-v3/include/bits/stl_bvector.h
> +++ b/libstdc++-v3/include/bits/stl_bvector.h
> @@ -593,6 +593,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> _GLIBCXX20_CONSTEXPR
> _Bvector_impl() _GLIBCXX_NOEXCEPT_IF(
>   is_nothrow_default_constructible<_Bit_alloc_type>::value)
> +#if __cpp_concepts
> +   requires is_default_constructible_v<_Bit_alloc_type>
> +#endif
> : _Bit_alloc_type()
> { }
>
> diff --git a/libstdc++-v3/include/bits/stl_vector.h 
> b/libstdc++-v3/include/bits/stl_vector.h
> index a8d387f40a1..31169711a48 100644
> --- a/libstdc++-v3/include/bits/stl_vector.h
> +++ b/libstdc++-v3/include/bits/stl_vector.h
> @@ -135,6 +135,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> _GLIBCXX20_CONSTEXPR
> _Vector_impl() _GLIBCXX_NOEXCEPT_IF(
> is_nothrow_default_constructible<_Tp_alloc_type>::value)
> +#if __cpp_lib_concepts
> +   requires is_default_constructible_v<_Tp_alloc_type>
> +#endif
> : _Tp_alloc_type()
> { }
>
> diff --git a/libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc 
> b/libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc
> new file mode 100644
> index 000..a7721d27f79
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc
> @@ -0,0 +1,34 @@
> +// { dg-do compile { target c++20 } }
> +
> +#include 
> +
> +template
> +struct Alloc
> +{
> +  using value_type = T;
> +
> +  Alloc(int) { } // not default constructible
> +
> +  template Alloc(const Alloc&) { }
> +
> +  T* allocate(std::size_t n) { return std::allocator().allocate(n); }
> +  void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, 
> n); }
> +};
> +
> +template struct wrap { T t; };
> +
> +template void do_adl(T&) { }
> +
> +void test_pr113841()
> +{
> +  using test_type = std::vector>;
> +  std::pair>* h = nullptr;
> +  do_adl(h);
> +}
> +
> +void test_pr113841_bool()
> +{
> +  using test_type = std::vector>;
> +  std::pair>* h = nullptr;
> +  do_adl(h);
> +}
> --
> 2.44.0
>



[committed] libstdc++: Reorder feature test macro definitions

2024-03-22 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

Put the C++23 generator and tuple_like ones before the C++26 ones.

libstdc++-v3/ChangeLog:

* include/bits/version.def (generator, tuple_like): Move earlier
in the file.
* include/bits/version.h: Regenerate.
---
 libstdc++-v3/include/bits/version.def | 34 +++
 libstdc++-v3/include/bits/version.h   | 40 +--
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 26e62c6a9b2..5ad44941bff 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1637,6 +1637,15 @@ ftms = {
   };
 };
 
+ftms = {
+  name = generator;
+  values = {
+v = 202207;
+cxxmin = 23;
+extra_cond = "__glibcxx_coroutine";
+  };
+};
+
 ftms = {
   name = ios_noreplace;
   values = {
@@ -1718,6 +1727,14 @@ ftms = {
   };
 };
 
+ftms = {
+  name = tuple_like;
+  values = {
+v = 202207;
+cxxmin = 23;
+  };
+};
+
 ftms = {
   name = unreachable;
   values = {
@@ -1771,23 +1788,6 @@ ftms = {
   };
 };
 
-ftms = {
-  name = generator;
-  values = {
-v = 202207;
-cxxmin = 23;
-extra_cond = "__glibcxx_coroutine";
-  };
-};
-
-ftms = {
-  name = tuple_like;
-  values = {
-v = 202207;
-cxxmin = 23;
-  };
-};
-
 // Standard test specifications.
 stds[97] = ">= 199711L";
 stds[03] = ">= 199711L";
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index 23c8c09ab4b..460a3e0116a 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1823,6 +1823,16 @@
 #endif /* !defined(__cpp_lib_forward_like) && 
defined(__glibcxx_want_forward_like) */
 #undef __glibcxx_want_forward_like
 
+#if !defined(__cpp_lib_generator)
+# if (__cplusplus >= 202100L) && (__glibcxx_coroutine)
+#  define __glibcxx_generator 202207L
+#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_generator)
+#   define __cpp_lib_generator 202207L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_generator) && defined(__glibcxx_want_generator) */
+#undef __glibcxx_want_generator
+
 #if !defined(__cpp_lib_ios_noreplace)
 # if (__cplusplus >= 202100L) && _GLIBCXX_HOSTED
 #  define __glibcxx_ios_noreplace 202207L
@@ -1913,6 +1923,16 @@
 #endif /* !defined(__cpp_lib_to_underlying) && 
defined(__glibcxx_want_to_underlying) */
 #undef __glibcxx_want_to_underlying
 
+#if !defined(__cpp_lib_tuple_like)
+# if (__cplusplus >= 202100L)
+#  define __glibcxx_tuple_like 202207L
+#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_tuple_like)
+#   define __cpp_lib_tuple_like 202207L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_tuple_like) && defined(__glibcxx_want_tuple_like) 
*/
+#undef __glibcxx_want_tuple_like
+
 #if !defined(__cpp_lib_unreachable)
 # if (__cplusplus >= 202100L)
 #  define __glibcxx_unreachable 202202L
@@ -1973,24 +1993,4 @@
 #endif /* !defined(__cpp_lib_to_string) && defined(__glibcxx_want_to_string) */
 #undef __glibcxx_want_to_string
 
-#if !defined(__cpp_lib_generator)
-# if (__cplusplus >= 202100L) && (__glibcxx_coroutine)
-#  define __glibcxx_generator 202207L
-#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_generator)
-#   define __cpp_lib_generator 202207L
-#  endif
-# endif
-#endif /* !defined(__cpp_lib_generator) && defined(__glibcxx_want_generator) */
-#undef __glibcxx_want_generator
-
-#if !defined(__cpp_lib_tuple_like)
-# if (__cplusplus >= 202100L)
-#  define __glibcxx_tuple_like 202207L
-#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_tuple_like)
-#   define __cpp_lib_tuple_like 202207L
-#  endif
-# endif
-#endif /* !defined(__cpp_lib_tuple_like) && defined(__glibcxx_want_tuple_like) 
*/
-#undef __glibcxx_want_tuple_like
-
 #undef __glibcxx_want_all
-- 
2.44.0



[committed] libstdc++: Use feature test macros in

2024-03-22 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

The preprocessor checks for __cplusplus in  should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.

For the latter, we want to check the compiler macro not the library's
__cpp_lib_constexpr_dynamic_alloc, because the latter is not defined for
freestanding but std::construct_at needs to be.

libstdc++-v3/ChangeLog:

* include/bits/stl_construct.h (destroy_at, construct_at): Guard
with feature test macros instead of just __cplusplus.
---
 libstdc++-v3/include/bits/stl_construct.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_construct.h 
b/libstdc++-v3/include/bits/stl_construct.h
index 7c394072b50..dc08fb7ea33 100644
--- a/libstdc++-v3/include/bits/stl_construct.h
+++ b/libstdc++-v3/include/bits/stl_construct.h
@@ -74,7 +74,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#if __cplusplus >= 201703L
+#if __glibcxx_raw_memory_algorithms // >= C++17
   template 
 _GLIBCXX20_CONSTEXPR inline void
 destroy_at(_Tp* __location)
@@ -88,7 +88,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__location->~_Tp();
 }
 
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   template
 constexpr auto
 construct_at(_Tp* __location, _Args&&... __args)
@@ -108,7 +108,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline void
 _Construct(_Tp* __p, _Args&&... __args)
 {
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   if (std::__is_constant_evaluated())
{
  // Allow std::_Construct to be used in constant expressions.
@@ -145,7 +145,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _GLIBCXX14_CONSTEXPR inline void
 _Destroy(_Tp* __pointer)
 {
-#if __cplusplus > 201703L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   std::destroy_at(__pointer);
 #else
   __pointer->~_Tp();
@@ -188,7 +188,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(is_destructible<_Value_type>::value,
"value type is destructible");
 #endif
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   if (std::__is_constant_evaluated())
return std::_Destroy_aux::__destroy(__first, __last);
 #endif
@@ -237,7 +237,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(is_destructible<_Value_type>::value,
"value type is destructible");
 #endif
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   if (std::__is_constant_evaluated())
return std::_Destroy_n_aux::__destroy_n(__first, __count);
 #endif
@@ -245,7 +245,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__destroy_n(__first, __count);
 }
 
-#if __cplusplus >= 201703L
+#if __glibcxx_raw_memory_algorithms // >= C++17
   template 
 _GLIBCXX20_CONSTEXPR inline void
 destroy(_ForwardIterator __first, _ForwardIterator __last)
-- 
2.44.0



[committed] libstdc++: Replace std::result_of with __invoke_result_t [PR114394]

2024-03-22 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

Replace std::result_of with std::invoke_result, as specified in the
standard since C++17, to avoid deprecated warnings for std::result_of.

We don't have __invoke_result_t in C++11 mode, so add it as an alias
template for __invoke_result<>::type (which is what std::result_of uses
as its base class, so there's no change in functionality).

This fixes warnings given by Clang 18.

libstdc++-v3/ChangeLog:

PR libstdc++/114394
* include/std/functional (bind): Use __invoke_result_t instead
of result_of::type.
* include/std/type_traits (__invoke_result_t): New alias
template.
* testsuite/20_util/bind/ref_neg.cc: Adjust prune pattern.
---
 libstdc++-v3/include/std/functional| 2 +-
 libstdc++-v3/include/std/type_traits   | 4 
 libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index e02be00abe5..766558b3ce0 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -556,7 +556,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
using _Res_type_impl
- = typename result_of< _Fn&(_Mu_type<_BArgs, _CallArgs>&&...) >::type;
+ = __invoke_result_t<_Fn&, _Mu_type<_BArgs, _CallArgs>&&...>;
 
   template
using _Res_type = _Res_type_impl<_Functor, _CallArgs, _Bound_args...>;
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 21402fd8c13..b441bf9908f 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -2664,6 +2664,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_Functor, _ArgTypes...
   >::type
 { };
+
+  // __invoke_result_t (std::invoke_result_t for C++11)
+  template
+using __invoke_result_t = typename __invoke_result<_Fn, _Args...>::type;
   /// @endcond
 
   template
diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index 4a1ed8dda5f..2db9fa8276a 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -50,7 +50,7 @@ void test02()
 
 // Ignore the reasons for deduction/substitution failure in the headers.
 // Arrange for the match to work on installed trees as well as build trees.
-// { dg-prune-output "no type named 'type' in 'struct std::result_of" }
+// { dg-prune-output "no type named 'type' in 'struct std::__invoke_result" }
 
 int main()
 {
-- 
2.44.0



Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

2024-03-21 Thread Jonathan Wakely
On Wed, 20 Mar 2024 at 18:11, François Dumont wrote:
>
> As proposed below I also updated gcc-13 branch.

Great, thanks.

>
>  libstdc++: [_GLIBCXX_DEBUG] Define __cpp_lib_null_iterators
>
>  _GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we
> can define
>  __cpp_lib_null_iterators macros like the normal mode.
>
>  libstdc++-v3/ChangeLog:
>
>  * include/std/iterator (__cpp_lib_null_iterators): Define
> regardless of
>  _GLIBCXX_DEBUG.
>  * include/std/version (__cpp_lib_null_iterators): Likewise.
>
> François
>
>
> On 20/03/2024 10:02, Jonathan Wakely wrote:
> > On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
> >> Thanks to you doc:
> >>
> >>   libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
> >>
> >>   _GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we
> >> can define
> >>   __glibcxx_null_iterators and __cpp_lib_null_iterators macros like
> >> the normal
> >>   mode.
> >>
> >>   libstdc++-v3/ChangeLog:
> >>
> >>   * version.def (null_iterators): Remove extra_cond.
> >>   * version.h: Regenerate.
> >>
> >> Ok to commit ?
> > Please don't bother talking about __glibcxx_null_iterators in the
> > commit message, that's an implementation detail that always mirrors
> > the standard-defined __cpp_lib_null_iterators one. The first line of
> > the commit will be much easier to read without that.
> >
> > OK with that change, thanks.
> >
> >> I already noticed that GCC 13 has no version.h file so no backport 
> >> question.
> > It has no version.h but it still has the macros:
> >
> > include/std/iterator:# define __cpp_lib_null_iterators 201304L
> > include/std/version:# define __cpp_lib_null_iterators 201304L
> >
> > Those definitions can be made to not depend on _GLIBCXX_DEBUG.
> >


Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

2024-03-20 Thread Jonathan Wakely
On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
>
> Thanks to you doc:
>
>  libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
>
>  _GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we
> can define
>  __glibcxx_null_iterators and __cpp_lib_null_iterators macros like
> the normal
>  mode.
>
>  libstdc++-v3/ChangeLog:
>
>  * version.def (null_iterators): Remove extra_cond.
>  * version.h: Regenerate.
>
> Ok to commit ?

Please don't bother talking about __glibcxx_null_iterators in the
commit message, that's an implementation detail that always mirrors
the standard-defined __cpp_lib_null_iterators one. The first line of
the commit will be much easier to read without that.

OK with that change, thanks.

> I already noticed that GCC 13 has no version.h file so no backport question.

It has no version.h but it still has the macros:

include/std/iterator:# define __cpp_lib_null_iterators 201304L
include/std/version:# define __cpp_lib_null_iterators 201304L

Those definitions can be made to not depend on _GLIBCXX_DEBUG.



[committed] libstdc++: Fix infinite loop in std::binomial_distribution [PR114359]

2024-03-19 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

Not a regression, but worth backporting.

-- >8 --

The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiplying
integers.

libstdc++-v3/ChangeLog:

PR libstdc++/114359
* include/bits/random.tcc (binomial_distribution::param_type):
Ensure arithmetic is done as type double.
* testsuite/26_numerics/random/binomial_distribution/114359.cc: New 
test.
---
 libstdc++-v3/include/bits/random.tcc |  2 +-
 .../random/binomial_distribution/114359.cc   | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 
libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc

diff --git a/libstdc++-v3/include/bits/random.tcc 
b/libstdc++-v3/include/bits/random.tcc
index ade416390b3..8216883c448 100644
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -1503,7 +1503,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  // sqrt(pi / 2)
  const double __spi_2 = 1.2533141373155002512078826424055226L;
  _M_s1 = std::sqrt(__np * __1p) * (1 + _M_d1 / (4 * __np));
- _M_s2 = std::sqrt(__np * __1p) * (1 + _M_d2 / (4 * _M_t * __1p));
+ _M_s2 = std::sqrt(__np * __1p) * (1 + _M_d2 / (4 * (_M_t * __1p)));
  _M_c = 2 * _M_d1 / __np;
  _M_a1 = std::exp(_M_c) * _M_s1 * __spi_2;
  const double __a12 = _M_a1 + _M_s2 * __spi_2;
diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc 
b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc
new file mode 100644
index 000..c1e4c380bf9
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc
@@ -0,0 +1,12 @@
+// { dg-do run { target c++11 } }
+
+// Bug 114359 - std::binomial_distribution hangs in infinite loop
+
+#include 
+
+int main()
+{
+  std::default_random_engine g{};
+  std::binomial_distribution b(1U << 30);
+  b(g);  // hangs forever
+}
-- 
2.44.0



[PATCH] libstdc++: Constrain std::vector default constructor [PR113841]

2024-03-19 Thread Jonathan Wakely
This fixes the problem in the PR, which is revealed by the new
concept-based constraints on std::pair constructors in C++20 mode. That
makes this a C++20 regression, as the PR's example compiles with C++17.

We need something similar for std::basic_string too, which I'll do
later.

Any comments?

Tested aarch64-linux.

-- >8 --

This is needed to avoid errors outside the immediate context when
evaluating is_default_constructible_v> when A is not
default constructible.

To avoid diagnostic regressions for 23_containers/vector/48101_neg.cc we
need to make the std::allocator partial specializations default
constructible, which they probably should have been anyway.

libstdc++-v3/ChangeLog:

PR libstdc++/113841
* include/bits/allocator.h (allocator): Add default
constructor to partial specializations for cv-qualified types.
* include/bits/stl_vector.h (_Vector_impl::_Vector_impl()):
Constrain so that it's only present if the allocator is default
constructible.
* include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()):
Likewise.
* testsuite/23_containers/vector/cons/113841.cc: New test.
---
 libstdc++-v3/include/bits/allocator.h |  3 ++
 libstdc++-v3/include/bits/stl_bvector.h   |  3 ++
 libstdc++-v3/include/bits/stl_vector.h|  3 ++
 .../23_containers/vector/cons/113841.cc   | 34 +++
 4 files changed, 43 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc

diff --git a/libstdc++-v3/include/bits/allocator.h 
b/libstdc++-v3/include/bits/allocator.h
index ff4f5b9137b..9e75b37fce7 100644
--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -254,6 +254,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
 public:
   typedef _Tp value_type;
+  allocator() { }
   template allocator(const allocator<_Up>&) { }
 };
 
@@ -262,6 +263,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
 public:
   typedef _Tp value_type;
+  allocator() { }
   template allocator(const allocator<_Up>&) { }
 };
 
@@ -270,6 +272,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
 public:
   typedef _Tp value_type;
+  allocator() { }
   template allocator(const allocator<_Up>&) { }
 };
   /// @endcond
diff --git a/libstdc++-v3/include/bits/stl_bvector.h 
b/libstdc++-v3/include/bits/stl_bvector.h
index a3343d95b36..d567e26f4e4 100644
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -593,6 +593,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_GLIBCXX20_CONSTEXPR
_Bvector_impl() _GLIBCXX_NOEXCEPT_IF(
  is_nothrow_default_constructible<_Bit_alloc_type>::value)
+#if __cpp_concepts
+   requires is_default_constructible_v<_Bit_alloc_type>
+#endif
: _Bit_alloc_type()
{ }
 
diff --git a/libstdc++-v3/include/bits/stl_vector.h 
b/libstdc++-v3/include/bits/stl_vector.h
index a8d387f40a1..31169711a48 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -135,6 +135,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_GLIBCXX20_CONSTEXPR
_Vector_impl() _GLIBCXX_NOEXCEPT_IF(
is_nothrow_default_constructible<_Tp_alloc_type>::value)
+#if __cpp_lib_concepts
+   requires is_default_constructible_v<_Tp_alloc_type>
+#endif
: _Tp_alloc_type()
{ }
 
diff --git a/libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc 
b/libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc
new file mode 100644
index 000..a7721d27f79
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/vector/cons/113841.cc
@@ -0,0 +1,34 @@
+// { dg-do compile { target c++20 } }
+
+#include 
+
+template
+struct Alloc
+{
+  using value_type = T;
+
+  Alloc(int) { } // not default constructible
+
+  template Alloc(const Alloc&) { }
+
+  T* allocate(std::size_t n) { return std::allocator().allocate(n); }
+  void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, n); 
}
+};
+
+template struct wrap { T t; };
+
+template void do_adl(T&) { }
+
+void test_pr113841()
+{
+  using test_type = std::vector>;
+  std::pair>* h = nullptr;
+  do_adl(h);
+}
+
+void test_pr113841_bool()
+{
+  using test_type = std::vector>;
+  std::pair>* h = nullptr;
+  do_adl(h);
+}
-- 
2.44.0



[PATCH] libstdc++: Use feature test macros in

2024-03-19 Thread Jonathan Wakely
Does anybody see any issues with making this change?

The __cpp_constexpr_dynamic_alloc macro is defined with -std=c++2a
since Clang 10.0.0 so this won't result in std::construct_at
disappearing by anybody using libstdc++ with Clang.

Tested x86_64-linux and aarch64-linux. Basic smoke tests checked with
Clang 16 too.

-- >8 --

The preprocessor checks for __cplusplus in  should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.

For the latter, we want to check the compiler macro not the library's
__cpp_lib_constexpr_dynamic_alloc, because the latter is not defined for
freestanding but std::construct_at needs to be.

libstdc++-v3/ChangeLog:

* include/bits/stl_construct.h (destroy_at, construct_at): Guard
with feature test macros instead of just __cplusplus.
---
 libstdc++-v3/include/bits/stl_construct.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_construct.h 
b/libstdc++-v3/include/bits/stl_construct.h
index 7c394072b50..dc08fb7ea33 100644
--- a/libstdc++-v3/include/bits/stl_construct.h
+++ b/libstdc++-v3/include/bits/stl_construct.h
@@ -74,7 +74,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#if __cplusplus >= 201703L
+#if __glibcxx_raw_memory_algorithms // >= C++17
   template 
 _GLIBCXX20_CONSTEXPR inline void
 destroy_at(_Tp* __location)
@@ -88,7 +88,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__location->~_Tp();
 }
 
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   template
 constexpr auto
 construct_at(_Tp* __location, _Args&&... __args)
@@ -108,7 +108,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline void
 _Construct(_Tp* __p, _Args&&... __args)
 {
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   if (std::__is_constant_evaluated())
{
  // Allow std::_Construct to be used in constant expressions.
@@ -145,7 +145,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _GLIBCXX14_CONSTEXPR inline void
 _Destroy(_Tp* __pointer)
 {
-#if __cplusplus > 201703L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   std::destroy_at(__pointer);
 #else
   __pointer->~_Tp();
@@ -188,7 +188,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(is_destructible<_Value_type>::value,
"value type is destructible");
 #endif
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   if (std::__is_constant_evaluated())
return std::_Destroy_aux::__destroy(__first, __last);
 #endif
@@ -237,7 +237,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(is_destructible<_Value_type>::value,
"value type is destructible");
 #endif
-#if __cplusplus >= 202002L
+#if __cpp_constexpr_dynamic_alloc // >= C++20
   if (std::__is_constant_evaluated())
return std::_Destroy_n_aux::__destroy_n(__first, __count);
 #endif
@@ -245,7 +245,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__destroy_n(__first, __count);
 }
 
-#if __cplusplus >= 201703L
+#if __glibcxx_raw_memory_algorithms // >= C++17
   template 
 _GLIBCXX20_CONSTEXPR inline void
 destroy(_ForwardIterator __first, _ForwardIterator __last)
-- 
2.44.0



  1   2   3   4   5   6   7   8   9   10   >