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.

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.

The <xlocale.h> header is needed for newlocale and locale_t on these
targets.

libstdc++-v3/ChangeLog:

	* acinclude.m4 (GLIBCXX_CHECK_TEXT_ENCODING): Use <xlocale.h> if
	needed for newlocale.
	* configure: Regenerate.
	* src/c++26/text_encoding.cc: Use <xlocale.h>.

Reviewed-by: Iain Sandoe <iain@sandoe.co.uk>

This is another C++26 change, approved in Varna 2023. We require a new
static array of data that is extracted from the IANA Character Sets
database. A new Python script to generate a header from the IANA CSV
file is added.

The text_encoding class is basically just a pointer to an {ID,name} pair
in the static array. The aliases view is also just the same pointer (or
empty), and the view's iterator moves forwards and backwards in the
array while the array elements have the same ID (or to one element
further, for a past-the-end iterator).

Because those iterators refer to a global array that never goes out of
scope, there's no reason they should every produce undefined behaviour
or indeterminate values.  They should either have well-defined
behaviour, or abort. The overhead of ensuring those properties is pretty
low, so seems worth it.

This means that an aliases_view iterator should never be able to access
out-of-bounds. A non-value-initialized iterator always points to an
element of the static array even when not dereferenceable (the array has
unreachable entries at the start and end, which means that even a
past-the-end iterator for the last encoding in the array still points to
valid memory).  Dereferencing an iterator can always return a valid
array element, or "" for a non-dereferenceable iterator (but doing so
will abort when assertions are enabled).  In the language being proposed
for C++26, dereferencing an invalid iterator erroneously returns "".
Attempting to increment/decrement past the last/first element in the
view is erroneously a no-op, so aborts when assertions are enabled, and
doesn't change value otherwise.

Similarly, constructing a std::text_encoding with an invalid id (one
that doesn't have the value of an enumerator) erroneously behaves the
same as constructing with id::unknown, or aborts with assertions
enabled.

libstdc++-v3/ChangeLog:

	PR libstdc++/113318
	* acinclude.m4 (GLIBCXX_CONFIGURE): Add c++26 directory.
	(GLIBCXX_CHECK_TEXT_ENCODING): Define.
	* config.h.in: Regenerate.
	* configure: Regenerate.
	* configure.ac: Use GLIBCXX_CHECK_TEXT_ENCODING.
	* include/Makefile.am: Add new headers.
	* include/Makefile.in: Regenerate.
	* include/bits/locale_classes.h (locale::encoding): Declare new
	member function.
	* include/bits/unicode.h (__charset_alias_match): New function.
	* include/bits/text_encoding-data.h: New file.
	* include/bits/version.def (text_encoding): Define.
	* include/bits/version.h: Regenerate.
	* include/std/text_encoding: New file.
	* src/Makefile.am: Add new subdirectory.
	* src/Makefile.in: Regenerate.
	* src/c++26/Makefile.am: New file.
	* src/c++26/Makefile.in: New file.
	* src/c++26/text_encoding.cc: New file.
	* src/experimental/Makefile.am: Include c++26 convenience
	library.
	* src/experimental/Makefile.in: Regenerate.
	* python/libstdcxx/v6/printers.py (StdTextEncodingPrinter): New
	printer.
	* scripts/gen_text_encoding_data.py: New file.
	* testsuite/22_locale/locale/encoding.cc: New test.
	* testsuite/ext/unicode/charset_alias_match.cc: New test.
	* testsuite/std/text_encoding/cons.cc: New test.
	* testsuite/std/text_encoding/members.cc: New test.
	* testsuite/std/text_encoding/requirements.cc: New test.

Reviewed-by: Ulrich Drepper <drepper.fsp@gmail.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>

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

libstdc++-v3/ChangeLog:

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

Now that _M_Detach do not reset iterator _M_version value we need to reset it when
the iterator is attached to a new sequence, even if this sequencer is null when
assigning a value-initialized iterator. In this case _M_version shall be resetted to 0.

libstdc++-v3/ChangeLog:

	PR libstdc++/112477
	* src/c++11/debug.cc
	(_Safe_iterator_base::_M_attach): Reset _M_version to 0 if attaching to null
	sequence.
	(_Safe_iterator_base::_M_attach_single): Likewise.
	(_Safe_local_iterator_base::_M_attach): Likewise.
	(_Safe_local_iterator_base::_M_attach_single): Likewise.
	* testsuite/23_containers/map/debug/112477.cc: New test case.

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

libstdc++-v3/ChangeLog:

	* src/filesystem/ops-common.h (stat_type): Use using.

Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

This patch made std::filesystem::equivalent correctly throw an exception
when either path does not exist as per [fs.op.equivalent]/4.

	PR libstdc++/113250

libstdc++-v3/ChangeLog:

	* src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&.
	* src/filesystem/ops.cc (fs::equivalent): Likewise.
	* testsuite/27_io/filesystem/operations/equivalent.cc: Handle
	error codes.
	* testsuite/experimental/filesystem/operations/equivalent.cc:
	Likewise.

Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

This implements the requirements in the following proposals, which
dictate how std::format deals with non-ASCII strings:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1868r1.html
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2572r1.html
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2675r1.pdf

There are two parts to this. The width estimation for strings must only
count the width of the first character in an extended grapheme cluster.
That requires implementing the algorithm for detecting cluster breaks,
which requires a number of lookup tables of the grapheme cluster break
properties (and Indic_Conjunct_Break and Extended_Pictographic
properties) of every code point. Additionally, some characters have a
field width of 2, which requires another lookup table of field widths
for every code point.  The tables added in this commit do not contain
entries for every code point from 0 to 0x10FFFF as that would be very
inefficient and use too much memory. Instead the tables only contain the
code points that form an "edge" for a property, omitting all the code
points that have the same property as the preceding one. We can use a
binary search to find the closest code point in the table that is not
greater than the one we're looking for.

The tables are generated by a new Python script added to the
contrib/unicode directory, and a new data file downloaded from the
Unicode Consortium website.

The rules for extended grapheme cluster breaking are implemented for the
latest Unicode standard, version 15.1.0.

libstdc++-v3/ChangeLog:

	* include/Makefile.am: Add new headers.
	* include/Makefile.in: Regenerate.
	* include/bits/unicode.h: New file.
	* include/bits/unicode-data.h: New file.
	* include/std/format: Include <bits/unicode.h>.
	(__literal_encoding_is_utf8): Move to <bits/unicode.h>.
	(_Spec::_M_fill): Change type to char32_t.
	(_Spec::_M_parse_fill_and_align): Read a Unicode scalar value
	instead of a single character.
	(__write_padded): Change __fill_char parameter to char32_t and
	encode it into the output.
	(__formatter_str::format): Use new __unicode::__field_width and
	__unicode::__truncate functions.
	* include/std/ostream: Adjust namespace qualification for
	__literal_encoding_is_utf8.
	* include/std/print: Likewise.
	* src/c++23/print.cc: Add [[unlikely]] attribute to error path.
	* testsuite/ext/unicode/view.cc: New test.
	* testsuite/std/format/functions/format.cc: Add missing examples
	from the standard demonstrating alignment with non-ASCII
	characters. Add examples checking correct handling of extended
	grapheme clusters.

contrib/ChangeLog:

	* unicode/README: Add notes about generating libstdc++ tables.
	* unicode/GraphemeBreakProperty.txt: New file.
	* unicode/emoji-data.txt: New file.
	* unicode/gen_libstdcxx_unicode_data.py: New file.

This prevents a std::filesystem::path from exceeding INT_MAX/4
components (which is unlikely to ever be a problem except on 16-bit
targets). That limit ensures that the capacity*1.5 calculation doesn't
overflow. We should also check that we don't exceed SIZE_MAX when
calculating how many bytes to allocate. That only needs to be checked
when int is at least as large as size_t, because otherwise we know that
the product INT_MAX/4 * sizeof(value_type) will fit in SIZE_MAX. For
targets where size_t is twice as wide as int this obviously holds. For
msp430-elf we have 16-bit int and 20-bit size_t, so the condition holds
as long as sizeof(value_type) fits in 7 bits, which it does.

We can also remove some floating-point arithmetic in operator/= which
ensures exponential growth of the buffer. That's redundant because
path::_List::reserve does that anyway (and does so more efficiently
since the commit immediately before this one).

libstdc++-v3/ChangeLog:

	* src/c++17/fs_path.cc (path::_List::reserve): Limit maximum
	size and check for overflows in arithmetic.
	(path::operator/=(const path&)): Remove redundant exponential
	growth calculation.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_path.cc (path::_List::reserve): Avoid
	floating-point arithmetic.