The std-clib.cc module definition file assumes that all names are
available unconditionally, but that's not true for all targets. Use the
same preprocessor conditions as are present in the <cxxx> headers.

A similar change is needed in std.cc.in for the <chrono> features that
depend on the SSO std::string, guarded with a __cpp_lib_chrono value
indicating full C++20 support.

The conditions for <cmath> are omitted from this change, as there are a
large number of them. That probably needs to be fixed.

libstdc++-v3/ChangeLog:

	PR libstdc++/118177
	* src/c++23/std-clib.cc.in: Use preprocessor conditions for
	names which are not always defined.
	* src/c++23/std.cc.in: Likewise.

The current check for negative times (i.e. before the epoch) only checks
for a negative number of seconds. For a time 1ms before the epoch the
seconds part will be zero, but the futex syscall will still fail with an
EINVAL error. Extend the check to handle this case.

This change adds a redundant check in the headers too, so that we avoid
even calling into the library for negative times. Both checks can be
marked [[unlikely]]. The check in the headers avoids the cost of
splitting the time into seconds and nanoseconds and then making a PLT
call. The check inside the library matches where we were checking
already, and fixes existing binaries that were compiled against older
headers but use a newer libstdc++.so.6 at runtime.

libstdc++-v3/ChangeLog:

	PR libstdc++/118093
	* include/bits/atomic_futex.h (_M_load_and_test_until_impl):
	Return false for times before the epoch.
	* src/c++11/futex.cc (_M_futex_wait_until): Extend check for
	negative times to check for subsecond times. Add unlikely
	attribute.
	(_M_futex_wait_until_steady): Likewise.
	* testsuite/30_threads/future/members/118093.cc: New test.

This implements the C++23 container adaptors std::flat_set and
std::flat_multiset from P1222R4.  The implementation is essentially
an simpler and pared down version of std::flat_map.

libstdc++-v3/ChangeLog:

	* include/Makefile.am: Add new header <flat_set>.
	* include/Makefile.in: Regenerate.
	* include/bits/version.def (__cpp_flat_set): Define.
	* include/bits/version.h: Regenerate
	* include/precompiled/stdc++.h: Include <flat_set>.
	* include/std/flat_set: New file.
	* src/c++23/std.cc.in: Export <flat_set>.
	* testsuite/23_containers/flat_multiset/1.cc: New test.
	* testsuite/23_containers/flat_set/1.cc: New test.

Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

This implements the C++23 container adaptors std::flat_map and
std::flat_multimap from P0429R9.  The implementation is shared
as much as possible between the two adaptors via a common base
class that's parameterized according to key uniqueness.

libstdc++-v3/ChangeLog:

	* include/Makefile.am: Add new header <flat_map>.
	* include/Makefile.in: Regenerate.
	* include/bits/alloc_traits.h (__not_allocator_like): New concept.
	* include/bits/stl_function.h (__transparent_comparator): Likewise.
	* include/bits/stl_iterator_base_types.h (__has_input_iter_cat):
	Likewise.
	* include/bits/uses_allocator.h (__allocator_for): Likewise.
	* include/bits/utility.h (sorted_unique_t): Define for C++23.
	(sorted_unique): Likewise.
	(sorted_equivalent_t): Likewise.
	(sorted_equivalent): Likewise.
	* include/bits/version.def (flat_map): Define.
	* include/bits/version.h: Regenerate.
	* include/precompiled/stdc++.h: Include <flat_map>.
	* include/std/flat_map: New file.
	* src/c++23/std.cc.in: Export <flat_map>.
	* testsuite/23_containers/flat_map/1.cc: New test.
	* testsuite/23_containers/flat_multimap/1.cc: New test.

Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

libstdc++-v3/ChangeLog:

	* src/c++17/fs_dir.cc: Fix typo in comment.

This avoids some warnings when building the std module.

libstdc++-v3/ChangeLog:

	* src/c++23/std.cc.in: Disable deprecated warnings when
	exporting std::rel_ops members.

This declares the range adaptor pipe operators a friend of the
_RangeAdaptorClosure base class so that the std module doesn't need to
export them for ADL to find them.

Note that we deliberately don't define these pipe operators as hidden
friends, see r14-3293-g4a6f3676e7dd9e.

libstdc++-v3/ChangeLog:

	* include/std/ranges (views::__adaptor::_RangeAdaptorClosure):
	Befriend both operator| overloads.
	* src/c++23/std.cc.in: Don't export views::__adaptor::operator|.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

Some tests were failing due to the exported using declaration of iter_move
conflicting with friend declarations; the exported using needs to be in the
inline namespace, like the customization point itself, rather than
std::ranges.

Also add a few missing exports.

Some tests failed to find some operators defined in implementation-detail
namespaces; this exports them as well, but as previously discussed it's
probably preferable to make those operators friends so ADL can find them
that way.

libstdc++-v3/ChangeLog:

	* src/c++23/std.cc.in: Fix iter_move/swap.  Add fold_left_first, to,
	concat, and some operators.

As described in PR 117630 the cow-stdexcept.cc file pulls in symbols
from system_error.cc, which are not actually needed there. Moving the
definition of error_category::_M_message to a separate file should solve
it.

libstdc++-v3/ChangeLog:

	PR libstdc++/117630
	* src/c++11/Makefile.am: Add new file.
	* src/c++11/Makefile.in: Regnerate.
	* src/c++11/cow-stdexcept.cc (error_category::_M_message): Move
	member function definition to ...
	* src/c++11/cow-system_error.cc: New file.

Standard JSON doesn't have comments, and it seems this file needs to be
conforming, not the common JSON-with-comments dialect.

libstdc++-v3/ChangeLog:

	* src/c++23/libstdc++.modules.json.in: Remove C++ comment.

This patch introduces an installed source form of module std and std.compat.
To help a build system find them, we install a libstdc++.modules.json file
alongside libstdc++.so, which tells the build system where the files are and
any special flags it should use when compiling them (none, in this case).
The format is from a proposal in SG15.  The build system can find this file
with 'gcc -print-file-name=libstdc++.modules.json'.

It seems preferable to use a relative path from this file to the sources so
that moving the installation doesn't break the reference, but I didn't see
any obvious way to compute that without relying on coreutils, perl, or
python, so I wrote a POSIX shell script for it.  The .. canonicalization
bits aren't necessary since I discovered $(abspath), but I guess I might as
well leave them in.

Currently this installs the sources under $(gxx_include_dir)/bits/,
i.e. /usr/include/c++/15/bits.  So with my -fsearch-include-path change,
std.cc can be compiled with g++ -fsearch-include-path bits/std.cc.  Note
that if someone actually tries to #include <bits/std.cc> it will fail with
"error: module control-line cannot be in included file".

Any ideas about a more user-friendly way to express "compile module std" are
welcome.

The sources currently have the extension .cc, like other source files.

std.cc started with m.cencora's implementation in PR114600.  I've made some
adjustments, but more is probably desirable, e.g. of the <algorithm>
handling of namespace ranges, and to remove exports of templates that are
only specialized in a particular header.  I've filled in a bunch of missing
exports, and added some FIXMEs where I noticed bits that are not implemented
yet.

Since bits/stdc++.h also intends to include the whole standard library, I
include it rather than duplicate it.  But stdc++.h comments out <execution>,
due to TBB issues; I include it separately and suppress TBB usage, so module
std won't currently provide parallel execution.

It seemed most convenient for the two files to be monolithic so we don't
need to worry about include paths.  So the C library names that module
std.compat exports in both namespace std and :: are a block of code that is
appended to both files, adjusted based on whether the macro STD_COMPAT is
defined before the block.

In this implementation std.compat imports std; it would also be valid for it
to duplicate everything in std.  I see the libc++ std.compat also imports
std.

As discussed in the PR, module std is supported in C++20 mode even though it
was added in C++23.

Changes to test module std will follow in a separate patch.  In my testing
I've noticed a few compiler bugs that break various testcases, so I don't
expect to enable module std testing by default at first.

	PR libstdc++/106852

libstdc++-v3/ChangeLog:

	* include/bits/version.def: Add __cpp_lib_modules.
	* include/bits/version.h: Regenerate.
	* src/c++23/Makefile.am: Add modules std and std.compat.
	* src/c++23/Makefile.in: Regenerate.
	* src/c++23/std-clib.cc.in: New file.
	* src/c++23/std.cc.in: New file.
	* src/c++23/std.compat.cc.in: New file.
	* src/c++23/libstdc++.modules.json.in: New file.

contrib/ChangeLog:

	* relpath.sh: New file.

Several member functions of filesystem::directory_iterator and
filesystem::recursive_directory_iterator currently dereference their
shared_ptr data member without checking for non-null. Because they use
operator-> and that function only uses _GLIBCXX_DEBUG_PEDASSERT rather
than __glibcxx_assert there is no assertion even when the library is
built with _GLIBCXX_ASSERTIONS defined. This means that dereferencing
invalid directory iterators gives an unhelpful segfault.

By using (*p). instead of p-> we get an assertion when the library is
built with _GLIBCXX_ASSERTIONS, with a "_M_get() != nullptr" message.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_dir.cc (fs::directory_iterator::operator*): Use
	shared_ptr::operator* instead of shared_ptr::operator->.
	(fs::recursive_directory_iterator::options): Likewise.
	(fs::recursive_directory_iterator::depth): Likewise.
	(fs::recursive_directory_iterator::recursion_pending): Likewise.
	(fs::recursive_directory_iterator::operator*): Likewise.
	(fs::recursive_directory_iterator::disable_recursion_pending):
	Likewise.

libstdc++-v3/ChangeLog:

	* src/c++11/cxx11-ios_failure.cc (__iosfail_type_info): Unhide
	the three-arg overload of __do_upcast.

The undefined std::ios_base_library_init() symbol that is referenced by
<iostream> is only supposed to be used for targets where symbol
versioning is supported.

The mingw-w64 target defaults to --enable-symvers=gnu due to using GNU
ld but doesn't actually support symbol versioning. This means it tries
to emit references to the std::ios_base_library_init() symbol, which
isn't really defined in the library. This causes problems when using lld
to link user binaries.

Disable the undefined symbol reference for non-ELF targets.

libstdc++-v3/ChangeLog:

	PR libstdc++/116159
	* include/std/iostream (ios_base_library_init): Only define for
	ELF targets.
	* src/c++98/ios_init.cc (ios_base_library_init): Likewise.

The recent change to use auto_win_file_handle for
std::filesystem::hard_link_count caused a regression. The
std::error_code argument should be cleared if no error occurs, but this
no longer happens. Add a call to ec.clear() in fs::hard_link_count to
fix this.

Also change the auto_win_file_handle class to take a reference to the
std::error_code and set it if an error occurs, to slightly simplify the
control flow in the fs::equiv_files function.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_ops.cc (auto_win_file_handle): Add error_code&
	member and set it if CreateFileW or GetFileInformationByHandle
	fails.
	(fs::equiv_files) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Simplify
	control flow.
	(fs::hard_link_count) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Clear ec
	on success.
	* testsuite/27_io/filesystem/operations/hard_link_count.cc:
	Check error handling.

libstdc++-v3/ChangeLog:

	* src/c++11/debug.cc: Replace throw() with noexcept.

This is LWG 4084 which I filed recently. LWG seems to support making the
change, so that std::num_put can use the %F format for floating-point
numbers.

libstdc++-v3/ChangeLog:

	PR libstdc++/114862
	* src/c++98/locale_facets.cc (__num_base::_S_format_float):
	Check uppercase flag for fixed format.
	* testsuite/22_locale/num_put/put/char/lwg4084.cc: New test.

libstdc++-v3/ChangeLog:

	* src/c++20/format.cc [!_GLIBCXX_HAS_GTHREADS] (mutex): Define
	dummy mutex type.
	* testsuite/std/time/format_localized.cc: Use loop variable
	instead of creating the same locale on every iteration.

The linux man page for strerror says that some systems return NULL for
an unknown error number. That violates the C and POSIX standards, but we
can esily handle it to avoid a segfault.

libstdc++-v3/ChangeLog:

	* src/c++11/system_error.cc (strerror_string): Handle
	non-conforming NULL return from strerror.

This implements the C++23 paper P2419R2 (Clarify handling of encodings
in localized formatting of chrono types). The requirement is that when
the literal encoding is "a Unicode encoding form" and the formatting
locale uses a different encoding, any locale-specific strings such as
"août" for std::chrono::August should be converted to the literal
encoding.

Using the recently-added std::locale::encoding() function we can check
the locale's encoding and then use iconv if a conversion is needed.
Because nl_langinfo_l and iconv_open both allocate memory, a naive
implementation would perform multiple allocations and deallocations for
every snippet of locale-specific text that needs to be converted to
UTF-8. To avoid that, a new internal locale::facet is defined to store
the text_encoding and an iconv_t descriptor, which are then cached in
the formatting locale. This requires access to the internals of a
std::locale object in src/c++20/format.cc, so that new file needs to be
compiled with -fno-access-control, as well as -std=gnu++26 in order to
use std::text_encoding.

Because the new std::text_encoding and std::locale::encoding() symbols
are only in the libstdc++exp.a archive, we need to include
src/c++26/text_encoding.cc in the main library, but not export its
symbols yet. This means they can be used by the two new functions which
are exported from the main library.

The encoding conversions are done for C++20, treating it as a DR that
resolves LWG 3656.

With this change we can increase the value of the __cpp_lib_format macro
for C++23. The value should be 202207 for P2419R2, but we already
implement P2510R3 (Formatting pointers) so can use the value 202304.

libstdc++-v3/ChangeLog:

	PR libstdc++/109162
	* acinclude.m4 (libtool_VERSION): Update to 6:34:0.
	* config/abi/pre/gnu.ver: Disambiguate old patters. Add new
	GLIBCXX_3.4.34 symbol version and new exports.
	* configure: Regenerate.
	* include/bits/chrono_io.h (_ChronoSpec::_M_locale_specific):
	Add new accessor functions to use a reserved bit in _Spec.
	(__formatter_chrono::_M_parse): Use _M_locale_specific(true)
	when chrono-specs contains locale-dependent conversion
	specifiers.
	(__formatter_chrono::_M_format): Open iconv descriptor if
	conversion to UTF-8 will be needed.
	(__formatter_chrono::_M_write): New function to write a
	localized string with possible character conversion.
	(__formatter_chrono::_M_a_A, __formatter_chrono::_M_b_B)
	(__formatter_chrono::_M_p, __formatter_chrono::_M_r)
	(__formatter_chrono::_M_x, __formatter_chrono::_M_X)
	(__formatter_chrono::_M_locale_fmt): Use _M_write.
	* include/bits/version.def (format): Update value.
	* include/bits/version.h: Regenerate.
	* include/std/format (_GLIBCXX_P2518R3): Check feature test
	macro instead of __cplusplus.
	(basic_format_context): Declare __formatter_chrono as friend.
	* src/c++20/Makefile.am: Add new file.
	* src/c++20/Makefile.in: Regenerate.
	* src/c++20/format.cc: New file.
	* testsuite/std/time/format_localized.cc: New test.
	* testsuite/util/testsuite_abi.cc: Add new symbol version.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_ops.cc: Fix file name in comment.

There are no inode numbers on Windows filesystems, so stat_type::st_ino
is always zero and the check for equivalent files in do_copy_file was
incorrectly identifying distinct files as equivalent. This caused
copy_file to incorrectly report errors when trying to overwrite existing
files.

The fs::equivalent function already does the right thing on Windows, so
factor that logic out into a new function that can be reused by
fs::copy_file.

The tests for fs::copy_file were quite inadequate, so this also adds
checks for that function's error conditions.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_ops.cc (auto_win_file_handle): Change constructor
	parameter from const path& to const wchar_t*.
	(fs::equiv_files): New function.
	(fs::equivalent): Use equiv_files.
	* src/filesystem/ops-common.h (fs::equiv_files): Declare.
	(do_copy_file): Use equiv_files.
	* src/filesystem/ops.cc (fs::equiv_files): Define.
	(fs::copy, fs::equivalent): Use equiv_files.
	* testsuite/27_io/filesystem/operations/copy.cc: Test
	overwriting directory contents recursively.
	* testsuite/27_io/filesystem/operations/copy_file.cc: Test
	overwriting existing files.

std::filesystem::hard_link_count() always returns 1 on
mingw-w64ucrt-11.0.1-r3 on Windows 10 19045

hard_link_count() queries _wstat64() on MinGW-w64
The MSFT documentation claims _wstat64() will always return 1 *non*-NTFS volumes
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120)



My tests suggest that is not always true -
hard_link_count()/_wstat64() still returns 1 on NTFS.
GetFileInformationByHandle does return the correct result of 2.
Please see the PR for a minimal repro.

This patch changes the Windows implementation to always call
GetFileInformationByHandle.

	PR libstdc++/113663

libstdc++-v3/ChangeLog:

	* src/c++17/fs_ops.cc (fs::equivalent): Moved helper class
	auto_handle to anonymous namespace as auto_win_file_handle.
	(fs::hard_link_count): Changed Windows implementation to use
	information provided by GetFileInformationByHandle which is more
	reliable.
	* testsuite/27_io/filesystem/operations/hard_link_count.cc: New
	test.

Signed-off-by: "Lennox" Shou Hao Ho <lennoxhoe@gmail.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

This avoids some warnings when the preprocessor conditions are not met.

libstdc++-v3/ChangeLog:

	* src/c++23/print.cc (__open_terminal): Use [[maybe_unused]] on
	parameter.

avrlibc has an incomplete unistd.h that doesn't have isatty.
So building libstdc++ fails when compiling c++23/print.cc.
As a workaround I added a check for AVR.

libstdc++-v3/ChangeLog:

	PR libstdc++/115482
	* src/c++23/print.cc (__open_terminal) [__AVR__]: Do not use
	isatty.

For the C locale we know the encoding is ASCII, so we can avoid using
newlocale and nl_langinfo_l. Similarly, for an unnamed locale, we aren't
going to get a useful answer, so we can just use a default-constrcuted
std::text_encoding representing an unknown encoding.

libstdc++-v3/ChangeLog:

	* src/c++26/text_encoding.cc (__locale_encoding): Add to unnamed
	namespace.
	(std::locale::encoding): Optimize for "C" and "*" names.

When the library is configured with --disable-libstdcxx-verbose the
assertions just abort instead of calling __glibcxx_assert_fail, and so I
didn't export that function for the non-verbose build. However, that
option is documented to not change the library ABI, so we still need to
export the symbol from the library. It could be needed by programs
compiled against the headers from a verbose build.

The non-verbose definition can just call abort so that it doesn't pull
in I/O symbols, which are unwanted in a non-verbose build.

libstdc++-v3/ChangeLog:

	PR libstdc++/115585
	* src/c++11/assert_fail.cc (__glibcxx_assert_fail): Add
	definition for non-verbose builds.

I found some issues in the std::chrono::tzdb parser by testing the
tzdata "vanguard" format, which uses new features that aren't enabled in
the "main" and "rearguard" data formats.

Since 2024a the keyword "minimum" is no longer valid for the FROM and TO
fields in a Rule line, which means that "m" is now a valid abbreviation
for "maximum". Previously we expected either "mi" or "ma". For backwards
compatibility, a FROM field beginning with "mi" is still supported and
is treated as 1900. The "maximum" keyword is only allowed in TO now,
because it makes no sense in FROM. To support these changes the
minmax_year and minmax_year2 classes for parsing FROM and TO are
replaced with a single years_from_to class that reads both fields.

The vanguard format makes use of %z in Zone FORMAT fields, which caused
an exception to be thrown from ZoneInfo::set_abbrev because no % or /
characters were expected when a Zone doesn't use a named Rule. The
ZoneInfo::to(sys_info&) function now uses format_abbrev_str to replace
any %z with the current offset. Although format_abbrev_str also checks
for %s and STD/DST formats, those only make sense when a named Rule is
in effect, so won't occur when ZoneInfo::to(sys_info&) is used.

This change also implements a feature that has always been missing from
time_zone::_M_get_sys_info: finding the Rule that is active before the
specified time point, so that we can correctly handle %s in the FORMAT
for the first new sys_info that gets created. This requires implementing
a poorly documented feature of zic, to get the LETTERS field from a
later transition, as described at
https://mm.icann.org/pipermail/tz/2024-April/058891.html
In order for this to work we need to be able to distinguish an empty
letters field (as used by CE%sT where the variable part is either empty
or "S") from "the letters field is not known for this transition". The
tzdata file uses "-" for an empty letters field, which libstdc++ was
previously replacing with "" when the Rule was parsed. Instead, we now
preserve the "-" in the Rule object, so that "" can be used for the case
where we don't know the letters (and so need to decide it).

libstdc++-v3/ChangeLog:

	* src/c++20/tzdb.cc (minmax_year, minmax_year2): Remove.
	(years_from_to): New class replacing minmax_year and
	minmax_year2.
	(format_abbrev_str, select_std_or_dst_abbrev): Move earlier in
	the file. Handle "-" for letters.
	(ZoneInfo::to): Use format_abbrev_str to expand %z.
	(ZoneInfo::set_abbrev): Remove exception. Change parameter from
	reference to value.
	(operator>>(istream&, Rule&)): Do not clear letters when it
	contains "-".
	(time_zone::_M_get_sys_info): Add missing logic to find the Rule
	in effect before the time point.
	* testsuite/std/time/tzdb/1.cc: Adjust for vanguard format using
	"GMT" as the Zone name, not as a Link to "Etc/GMT".
	* testsuite/std/time/time_zone/sys_info_abbrev.cc: New test.

Several of the 19_diagnostics/stacktrace tests FAIL on Solaris/SPARC (32
and 64-bit), Solaris/x86 (32-bit only), and several other targets:

FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test

As it turns out, both the copy of libbacktrace in libstdc++ and the
testcases proper need to compiled with -funwind-tables, as is done for
libbacktrace itself.

This isn't an issue on Linux/x86_64 and Solaris/amd64 since 64-bit x86
always defaults to -funwind-tables.  32-bit x86 does, too, when
-fomit-frame-pointer is enabled as on Linux/i686, but unlike
Solaris/i386.

So this patch always enables the option both for the libbacktrace copy
and the testcases.

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

2024-05-23  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libstdc++-v3:
	PR libstdc++/111641
	* src/libbacktrace/Makefile.am (AM_CFLAGS): Add -funwind-tables.
	* src/libbacktrace/Makefile.in: Regenerate.

	* testsuite/19_diagnostics/stacktrace/current.cc (dg-options): Add
	-funwind-tables.
	* 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.

This fixes a bug in locale::combine where we fail to meet the standard's
requirement that the result is unnamed. It also implements two library
issues related to the names of combined locales (2295 and 3676).

libstdc++-v3/ChangeLog:

	PR libstdc++/108323
	* include/bits/locale_classes.tcc (locale(const locale&, Facet*)):
	Return a copy of the first argument when the facet pointer is
	null, as per LWG 2295.
	(locale::combine): Ensure the result is unnamed.
	* src/c++11/localename.cc (_M_replace_categories): Ignore
	whether the second locale has a name when cat == none, as per
	LWG 3676.
	* src/c++98/locale.cc (_M_install_facet): Use __builtin_expect
	to predict that the facet pointer is non-null.
	* testsuite/22_locale/locale/cons/names.cc: New test.

Do not use dynamic_cast unconditionally, in case libstdc++ is built with
-fno-rtti.

libstdc++-v3/ChangeLog:

	PR libstdc++/115015
	* src/c++23/print.cc (__open_terminal(streambuf*)) [!__cpp_rtti]:
	Do not use dynamic_cast.

The recent move of libgfortran object files to subdirs and the resulting
breakage of libgfortran.so symbol exports demonstrated how fragile
deriving object and archive names from their libtool counterparts in the
Makefiles is.  Therefore, this patch moves that step into
make_sunver.pl, considerably simplifying the Makefile rules to create
the version scripts.

Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, verifying that the version scripts are identical
except for the input filenames.

2024-05-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	contrib:
	* make_sunver.pl: Use File::Basename;
	Skip -lLIB args.
	Convert libtool object/archive names to underlying
	objects/archives.

	libatomic:
	* Makefile.am [LIBAT_BUILD_VERSIONED_SHLIB_SUN]
	(libatomic.map-sun): Pass $(libatomic_la_OBJECTS),
	$(libatomic_la_LIBADD) to make_sunver.pl unmodified.
	* Makefile.in: Regenerate.

	libffi:
	* Makefile.am [LIBFFI_BUILD_VERSIONED_SHLIB_SUN] (libffi.map-sun):
	Pass $(libffi_la_OBJECTS), $(libffi_la_LIBADD) to make_sunver.pl
	unmodified.
	* Makefile.in: Regenerate.

	libgfortran:
	* Makefile.am [LIBGFOR_USE_SYMVER_SUN} (gfortran.ver-sun): Pass
	$(libgfortran_la_OBJECTS), $(libgfortran_la_LIBADD) to
	make_sunver.pl unmodified.
	* Makefile.in: Regenerate.

	libgomp:
	* Makefile.am [LIBGOMP_BUILD_VERSIONED_SHLIB_SUN]
	(libgomp.ver-sun): Pass $(libgomp_la_OBJECTS),
	$(libgomp_la_LIBADD) to make_sunver.pl unmodified.
	* Makefile.in: Regenerate.

	libitm:
	* Makefile.am [LIBITM_BUILD_VERSIONED_SHLIB_SUN] (libitm.map-sun):
	Pass $(libitm_la_OBJECTS), $(libitm_la_LIBADD) to make_sunver.pl
	unmodified.
	* Makefile.in: Regenerate.

	libquadmath:
	* Makefile.am [LIBQUAD_USE_SYMVER_SUN] (quadmath.map-sun): Pass
	$(libquadmath_la_OBJECTS), $(libquadmath_la_LIBADD) to
	make_sunver.pl unmodified.
	* Makefile.in: Regenerate.

	libssp:
	* Makefile.am [LIBSSP_USE_SYMVER_SUN] (ssp.map-sun): Pass
	$(libssp_la_OBJECTS), $(libssp_la_LIBADD) to make_sunver.pl
	unmodified.
	* Makefile.in: Regenerate.

	libstdc++-v3:
	* src/Makefile.am [ENABLE_SYMVERS_SUN]
	(libstdc++-symbols.ver-sun): Pass $(libstdc___la_OBJECTS),
	$(libstdc___la_LIBADD) to make_sunver.pl unmodified.
	* src/Makefile.in: Regenerate.

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.

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.


for  libstdc++-v3/ChangeLog

	* src/c++20/tzdb.cc (__gnu_cxx::zoneinfo_dir_override): Define
	on VxWorks non-RTP.

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.

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.

The whole point of these typedefs is to guarantee lock-freedom, so if
the target has no such types, we shouldn't defined the typedefs at all.

libstdc++-v3/ChangeLog:

	PR libstdc++/114103
	* include/bits/version.def (atomic_lock_free_type_aliases): Add
	extra_cond to check for at least one always-lock-free type.
	* include/bits/version.h: Regenerate.
	* include/std/atomic (atomic_signed_lock_free)
	(atomic_unsigned_lock_free): Only use always-lock-free types.
	* src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): Don't use
	atomic counter if lock-free aliases aren't available.
	* testsuite/29_atomics/atomic/lock_free_aliases.cc: XFAIL for
	targets without lock-free word-size compare_exchange.

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

libstdc++-v3/ChangeLog:

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