aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/src
AgeCommit message (Collapse)AuthorFilesLines
2024-05-29libstdc++: Build libbacktrace and 19_diagnostics/stacktrace with ↵Rainer Orth2-2/+2
-funwind-tables [PR111641] 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.
2024-05-22libstdc++: Fix effects of combining locales [PR108323]Jonathan Wakely2-2/+4
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.
2024-05-14libstdc++: Guard dynamic_cast use in src/c++23/print.cc [PR115015]Jonathan Wakely1-1/+1
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.
2024-05-07build: Derive object names in make_sunver.plRainer Orth2-6/+2
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.
2024-04-19libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]Jonathan Wakely1-4/+53
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.
2024-04-18[libstdc++] define zoneinfo_dir_override on vxworksAlexandre Oliva1-2/+3
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.
2024-04-15libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]Jonathan Wakely1-2/+11
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.
2024-04-10libstdc++: Handle EMLINK and EFTYPE in std::filesystem::remove_allJonathan Wakely1-2/+14
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.
2024-03-07libstdc++: Do not define lock-free atomic aliases if not fully lock-free ↵Jonathan Wakely1-1/+6
[PR114103] 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.
2024-02-15libstdc++: Update tzdata to 2024aJonathan Wakely2-1988/+1986
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.
2024-02-04libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbolsJonathan Wakely4-9/+38
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.
2024-01-31libstdc++: Enable std::text_encoding for darwin and FreeBSDJonathan Wakely1-0/+3
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>
2024-01-17libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]Jonathan Wakely7-4/+957
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>
2024-01-15libstdc++: Update tzdata to 2023dJonathan Wakely2-8/+19
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.
2024-01-11libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator ↵François Dumont1-0/+8
[PR112477] 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>
2024-01-11libstdc++: Use using instead of typedef in opts-common.hKen Matsui1-2/+2
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>
2024-01-11libstdc++: Fix error handling in filesystem::equivalent [PR113250]Ken Matsui2-2/+2
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>
2024-01-08libstdc++: Add Unicode-aware width estimation for std::formatJonathan Wakely1-1/+1
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.
2024-01-05libstdc++: Avoid overflow when appending to std::filesystem::pathJonathan Wakely1-11/+24
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.
2024-01-05libstdc++: Remove unneeded double operation in src/c++17/fs_path.ccMartin Küttler1-2/+3
libstdc++-v3/ChangeLog: * src/c++17/fs_path.cc (path::_List::reserve): Avoid floating-point arithmetic.
2024-01-05Update copyright years.Jakub Jelinek1-1/+1
2024-01-03Update copyright years.Jakub Jelinek138-138/+138
2023-12-16libstdc++: Fix bootstrap on AIX due to fileno macroJonathan Wakely1-1/+1
On AIX fileno is a function-like macro, so enclose the name in parentheses to ensure we use the real function. libstdc++-v3/ChangeLog: * src/c++23/print.cc (__open_terminal(FILE*)): Avoid fileno macro.
2023-12-15libstdc++: Fix std::print test case for WindowsJonathan Wakely1-1/+12
libstdc++-v3/ChangeLog: * src/c++23/print.cc (__write_to_terminal) [_WIN32]: If handle does not refer to the console then just write to it using normal file I/O. * testsuite/27_io/print/2.cc (as_printed_to_terminal): Print error message on failure. (test_utf16_transcoding): Adjust for as_printed_to_terminal modifying its argument.
2023-12-14libstdc++: Implement C++23 <print> header [PR107760]Jonathan Wakely3-3/+363
This adds the C++23 std::print functions, which use std::format to write to a FILE stream or std::ostream (defaulting to stdout). The new extern symbols are in the libstdc++exp.a archive, so we aren't committing to stable symbols in the DSO yet. There's a UTF-8 validating and transcoding function added by this change. That can certainly be optimized, but it's internal to libstdc++exp.a so can be tweaked later at leisure. Currently the external symbols work for all targets, but are only actually used for Windows, where it's necessary to transcode to UTF-16 to write to the console. The standard seems to encourage us to also diagnose invalid UTF-8 for non-Windows targets when writing to a terminal (and only when writing to a terminal), but I'm reliably informed that that wasn't the intent of the wording. Checking for invalid UTF-8 sequences only needs to happen for Windows, which is good as checking for a terminal requires a call to isatty, and on Linux that uses an ioctl syscall, which would make std::print ten times slower! Testing the std::print behaviour is difficult if it depends on whether the output stream is connected to a Windows console or not, as we can't (as far as I know) do that non-interactively in DejaGNU. One of the new tests uses the internal __write_to_terminal function directly. That allows us to verify its UTF-8 error handling on POSIX targets, even though that's not actually used by std::print. For Windows, that __write_to_terminal function transcodes to UTF-16 but then uses WriteConsoleW which fails unless it really is writing to the console. That means the 27_io/print/2.cc test FAILs on Windows. The UTF-16 transcoding has been manually tested using mingw-w64 and Wine, and appears to work. libstdc++-v3/ChangeLog: PR libstdc++/107760 * include/Makefile.am: Add new header. * include/Makefile.in: Regenerate. * include/bits/version.def (__cpp_lib_print): Define. * include/bits/version.h: Regenerate. * include/std/format (__literal_encoding_is_utf8): New function. (_Seq_sink::view()): New member function. * include/std/ostream (vprintf_nonunicode, vprintf_unicode) (print, println): New functions. * include/std/print: New file. * src/c++23/Makefile.am: Add new source file. * src/c++23/Makefile.in: Regenerate. * src/c++23/print.cc: New file. * testsuite/27_io/basic_ostream/print/1.cc: New test. * testsuite/27_io/print/1.cc: New test. * testsuite/27_io/print/2.cc: New test.
2023-12-12libstdc++: Remove redundant -std flags from MakefileJonathan Wakely2-8/+8
In r14-4060-gc4baeaecbbf7d0 I moved some files from src/c++98 to src/c++11 but I didn't remove the redundant -std=gnu++11 flags for those files. The flags aren't needed now, because AM_CXXFLAGS for that directory already uses -std=gnu++11. This removes them. libstdc++-v3/ChangeLog: * src/c++11/Makefile.am: Remove redundant -std=gnu++11 flags. * src/c++11/Makefile.in: Regenerate.
2023-11-07libstdc++/112351 - deal with __gthread_once failure during locale initRichard Biener1-5/+8
The following makes the C++98 locale init path follow the way the C++11 performs initialization. This way we deal with pthread_once failing, falling back to non-threadsafe initialization which, given we initialize from the library, should be serialized by the dynamic loader already. PR libstdc++/112351 libstdc++-v3/ * src/c++98/locale.cc (locale::facet::_S_initialize_once): Check whether _S_c_locale is already initialized. (locale::facet::_S_get_c_locale): Always perform non-threadsafe init when threadsafe init failed.
2023-11-04libstdc++: Use strerror_r in std::generic_category()::message(int) [PR110133]Jonathan Wakely1-8/+70
Use strerror_r instead of strerror when available, due to the latter not being thread-safe. This is complicated by Glibc providing a GNU-specific strerror_r which is not compatible with POSIX strerror_r, so we need to dispatch on the return type. We can use the recently-added std::string::__resize_and_overwrite to write directly into the string buffer when possible. Because we estimate the initial buffer size we might end up with excess capacity in the returned std::string. We can slightly tweak the std::system_error constructors to make use of that excess capacity, so that in some cases we require fewer allocations to construct the std::system_error::what() string. libstdc++-v3/ChangeLog: PR libstdc++/110133 * include/std/system_error (system_error::system_error): Group arguments so that concatenation can reuse rvalue's capacity. * src/c++11/system_error.cc (strerror_string): New function. [_GLIBCXX_HAVE_STRERROR_R] (use_strerror_result): New functions. (generic_error_category::message): Use strerror_string. (system_error_category::message): Likewise.
2023-10-30libstdc++: [_GLIBCXX_INLINE_VERSION] Un-weak handle_contract_violationFrançois Dumont1-2/+3
libstdc++-v3/ChangeLog: * src/experimental/contract.cc [_GLIBCXX_INLINE_VERSION](handle_contract_violation): Rework comment. Remove weak attribute.
2023-10-29libstdc++: [_GLIBCXX_INLINE_VERSION] Provide handle_contract_violation symbolFrançois Dumont1-0/+8
libstdc++-v3/ChangeLog: * src/experimental/contract.cc [_GLIBCXX_INLINE_VERSION](handle_contract_violation): Provide symbol without version namespace decoration for gcc.
2023-10-25libstdc++: Build libstdc++_libbacktrace.a as PIC [PR111936]Jonathan Wakely2-5/+10
In order for std::stacktrace to be used in a shared library, the libbacktrace symbols need to be built with -fPIC. Add the libtool -prefer-pic flag to the commands in src/libbacktrace/Makefile so that the archive contains PIC objects. libstdc++-v3/ChangeLog: PR libstdc++/111936 * src/libbacktrace/Makefile.am: Add -prefer-pic to libtool compile commands. * src/libbacktrace/Makefile.in: Regenerate.
2023-10-22Config,Darwin: Allow for configuring Darwin to use embedded runpath.Iain Sandoe2-2/+10
Recent Darwin versions place contraints on the use of run paths specified in environment variables. This breaks some assumptions in the GCC build. This change allows the user to configure a Darwin build to use '@rpath/libraryname.dylib' in library names and then to add an embedded runpath to executables (and libraries with dependents). The embedded runpath is added by default unless the user adds '-nodefaultrpaths' to the link line. For an installed compiler, it means that any executable built with that compiler will reference the runtimes installed with the compiler (equivalent to hard-coding the library path into the name of the library). During build-time configurations any "-B" entries will be added to the runpath thus the newly-built libraries will be found by exes. Since the install name is set in libtool, that decision needs to be available here (but might also cause dependent ones in Makefiles, so we need to export a conditional). This facility is not available for Darwin 8 or earlier, however the existing environment variable runpath does work there. We default this on for systems where the external DYLD_LIBRARY_PATH does not work and off for Darwin 8 or earlier. For systems that can use either method, if the value is unset, we use the default (which is currently DYLD_LIBRARY_PATH). ChangeLog: * configure: Regenerate. * configure.ac: Do not add default runpaths to GCC exes when we are building -static-libstdc++/-static-libgcc (the default). * libtool.m4: Add 'enable-darwin-at-runpath'. Act on the enable flag to alter Darwin libraries to use @rpath names. gcc/ChangeLog: * aclocal.m4: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths. * config/darwin.h: Handle Darwin rpaths. * config/darwin.opt: Handle Darwin rpaths. * Makefile.in: Handle Darwin rpaths. gcc/ada/ChangeLog: * gcc-interface/Makefile.in: Handle Darwin rpaths. gcc/jit/ChangeLog: * Make-lang.in: Handle Darwin rpaths. libatomic/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths. libbacktrace/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. libgcc/ChangeLog: * config/t-slibgcc-darwin: Generate libgcc_s with an @rpath name. * config.host: Handle Darwin rpaths. libgfortran/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths libgm2/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths. * libm2cor/Makefile.am: Handle Darwin rpaths. * libm2cor/Makefile.in: Regenerate. * libm2iso/Makefile.am: Handle Darwin rpaths. * libm2iso/Makefile.in: Regenerate. * libm2log/Makefile.am: Handle Darwin rpaths. * libm2log/Makefile.in: Regenerate. * libm2min/Makefile.am: Handle Darwin rpaths. * libm2min/Makefile.in: Regenerate. * libm2pim/Makefile.am: Handle Darwin rpaths. * libm2pim/Makefile.in: Regenerate. libgomp/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths libitm/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths. libobjc/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths. libphobos/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths. * libdruntime/Makefile.am: Handle Darwin rpaths. * libdruntime/Makefile.in: Regenerate. * src/Makefile.am: Handle Darwin rpaths. * src/Makefile.in: Regenerate. libquadmath/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths. libsanitizer/ChangeLog: * asan/Makefile.am: Handle Darwin rpaths. * asan/Makefile.in: Regenerate. * configure: Regenerate. * hwasan/Makefile.am: Handle Darwin rpaths. * hwasan/Makefile.in: Regenerate. * lsan/Makefile.am: Handle Darwin rpaths. * lsan/Makefile.in: Regenerate. * tsan/Makefile.am: Handle Darwin rpaths. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.am: Handle Darwin rpaths. * ubsan/Makefile.in: Regenerate. libssp/ChangeLog: * Makefile.am: Handle Darwin rpaths. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Handle Darwin rpaths. libstdc++-v3/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths. * src/Makefile.am: Handle Darwin rpaths. * src/Makefile.in: Regenerate. libvtv/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths. lto-plugin/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths. zlib/ChangeLog: * configure: Regenerate. * configure.ac: Handle Darwin rpaths.
2023-09-29libstdc++: Fix handling of surrogate CP in codecvt [PR108976]Dimitrij Mijoski1-9/+9
This patch fixes the handling of surrogate code points in all standard facets for transcoding Unicode that are based on std::codecvt. Surrogate code points should always be treated as error. On the other hand surrogate code units can only appear in UTF-16 and only when they come in a proper pair. Additionally, it fixes a bug in std::codecvt_utf16::in() when odd number of bytes were given in the range [from, from_end), error was returned always. The last byte in such range does not form a full UTF-16 code unit and we can not make any decisions for error, instead partial should be returned. The testsuite for testing these facets was updated in the following order: 1. All functions that test codecvts that work with UTF-8 were refactored and made more generic so they accept codecvt that works with the char type char8_t. 2. The same functions were updated with new test cases for transcoding errors and now additionally test for surrogates, overlong UTF-8 sequences, code points out of the Unicode range, and more tests for missing leading and trailing code units. 3. New tests were added to test codecvt_utf16 in both of its variants, UTF-16 <-> UTF-32/UCS-4 and UTF-16 <-> UCS-2. libstdc++-v3/ChangeLog: PR libstdc++/108976 * src/c++11/codecvt.cc (read_utf8_code_point): Fix handing of surrogates in UTF-8. (ucs4_out): Fix handling of surrogates in UCS-4 -> UTF-8. (ucs4_in): Fix handling of range with odd number of bytes. (ucs4_out): Fix handling of surrogates in UCS-4 -> UTF-16. (ucs2_out): Fix handling of surrogates in UCS-2 -> UTF-16. (ucs2_in): Fix handling of range with odd number of bytes. (__codecvt_utf16_base<char16_t>::do_in): Likewise. (__codecvt_utf16_base<char32_t>::do_in): Likewise. (__codecvt_utf16_base<wchar_t>::do_in): Likewise. * testsuite/22_locale/codecvt/codecvt_unicode.cc: Renames, add tests for codecvt_utf16<char16_t> and codecvt_utf16<char32_t>. * testsuite/22_locale/codecvt/codecvt_unicode.h: Refactor UTF-8 testing functions for char8_t, add more test cases for errors, add testing functions for codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_unicode_wchar_t.cc: Renames, add tests for codecvt_utf16<whchar_t>. * testsuite/22_locale/codecvt/codecvt_utf16/79980.cc (test06): Fix test. * testsuite/22_locale/codecvt/codecvt_unicode_char8_t.cc: New test.
2023-09-15libstdc++: Implement C++26 native handles for file streams (P1759R6)Jonathan Wakely6-55/+67
The new __basic_file::native_handle() function can be added for C++11 and above, because the names "native_handle" and "native_handle_type" are already reserved since C++11. Exporting those symbols from the shared library does no harm, even if the feature gets dropped before the C++23 standard is final. The new member functions of std::fstream etc. are only declared for C++26 and so are not instantiated in src/c++11/fstream-inst.cc. Declare them with the always_inline attribute so that no symbol definitions are needed in the library (we can change this later when C++26 support is less experimental). libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES): New macro. * config.h.in: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export new basic_filebuf members. * config/io/basic_file_stdio.cc (__basic_file::native_handle): Define new function. * config/io/basic_file_stdio.h (__basic_file::native_handle): Declare new function. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES. * include/bits/version.def (fstream_native_handles): New macro. * include/bits/version.h: Regenerate. * include/std/fstream (basic_filebuf::native_handle) (basic_fstream::native_handle, basic_ifstream::native_handle) (basic_ofstream::native_handle): New functions. * src/c++11/Makefile.am: Move compilation of basic_file.cc, locale_init.cc and localename.cc to here. * src/c++11/Makefile.in: Regenerate. * src/c++98/locale_init.cc: Moved to... * src/c++11/locale_init.cc: ...here. * src/c++98/localename.cc: Moved to... * src/c++11/localename.cc: ...here. * src/c++98/Makefile.am: Remove basic_file.cc, locale_init.cc and localename.cc from here. * src/c++98/Makefile.in: Regenerate. * testsuite/27_io/basic_filebuf/native_handle/version.cc: New test. * testsuite/27_io/basic_fstream/native_handle/char/1.cc: New test. * testsuite/27_io/basic_fstream/native_handle/wchar_t/1.cc: New test. * testsuite/27_io/basic_ifstream/native_handle/char/1.cc: New test. * testsuite/27_io/basic_ifstream/native_handle/wchar_t/1.cc: New test. * testsuite/27_io/basic_ofstream/native_handle/char/1.cc: New test. * testsuite/27_io/basic_ofstream/native_handle/wchar_t/1.cc: New test.
2023-09-14libstdc++: Remove some more unconditional uses of atomicsJonathan Wakely2-18/+23
These atomics cause linker errors on arm4t where __sync_synchronize is not defined. For single-threaded targets we don't need the atomics. libstdc++-v3/ChangeLog: * include/experimental/io_context (io_context) [!_GLIBCXX_HAS_GTHREADS]: Use a plain integer for _M_work_count for single-threaded targets. * include/experimental/memory_resource (__get_default_resource) [!_GLIBCXX_HAS_GTHREADS]: Use unsynchronized type for single-threaded targets. * src/c++17/default_resource.h: Adjust preprocessor conditions to match memory_resource.cc. * src/c++17/memory_resource.cc [!_GLIBCXX_HAS_GTHREADS] (atomic_mem_res): Use unsynchronized type for single-threaded targets.
2023-09-11libstdc++: Remove unconditional use of atomics in Debug ModeJonathan Wakely1-3/+29
The fix for PR 91910 (r10-3426-gf7a3a382279585) introduced unconditional uses of atomics into src/c++11/debug.cc, which causes linker errors for arm4t where GCC emits an unresolved reference to __sync_synchronize. By making the uses of atomics depend on _GLIBCXX_HAS_GTHREADS we can avoid those unconditional references to __sync_synchronize for targets where the atomics are unnecessary. As a minor performance optimization we can also check the __gnu_cxx::__is_single_threaded function to avoid atomics for single-threaded programs even where they don't cause linker errors. libstdc++-v3/ChangeLog: * src/c++11/debug.cc (acquire_sequence_ptr_for_lock): New function. (reset_sequence_ptr): New function. (_Safe_iterator_base::_M_detach) (_Safe_local_iterator_base::_M_detach): Replace bare atomic_load with acquire_sequence_ptr_for_lock. (_Safe_iterator_base::_M_reset): Replace bare atomic_store with reset_sequence_ptr.
2023-09-11libstdc++: Move __glibcxx_assert_fail to its own fileJonathan Wakely4-21/+49
This avoids a dependency on the other symbols in src/c++11/debug.o when linking statically to libstdc++.a without using -Wl,--gc-sections. libstdc++-v3/ChangeLog: * src/c++11/Makefile.am: Add new file. * src/c++11/Makefile.in: Regenerate. * src/c++11/debug.cc (__glibcxx_assert_fail): Move to ... * src/c++11/assert_fail.cc: New file.
2023-09-11libstdc++: Fix -Wunused-parameter warningsPekka Seppänen3-4/+5
Fix -Wunused-parameter warnings when _GLIBCXX_USE_WCHAR_T is not defined. libstdc++-v3/ChangeLog: * src/c++11/cow-locale_init.cc: Add [[maybe_unused]] attribute. * src/c++17/fs_path.cc (path::_S_convert_loc): Likewise. * src/filesystem/path.cc (path::_S_convert_loc): Likewise. Signed-off-by: Pekka Seppänen <pexu@gcc.mail.kapsi.fi>
2023-09-08libstdc++: Add Filesystem TS and std::stacktrace symbols to libstdc++exp.aJonathan Wakely11-78/+1090
This consolidates the three static archives for extensions into one, so that -lstdc++exp can be used to provide the definitions of all unstable library features. The libstdc++_libbacktrace.a archive is now just a "noinst" convenience library that is only used during the build, not installed. Its contents are added to libstdc++exp.a, along with the new non-inline definitions of std::stacktrace symbols. The libstdc++fs.a archive is still installed, but its contents are duplicated in libstdc++exp.a now. This means -lstdc++exp can be used instead of -lstdc++fs. For targets using the GNU linker we should consider replacing libstdc++fs.a with a linker script that does INPUT(libstdc++exp.a). The tests for <experimental/filesystem> could be changed to use -lstdc++exp instead of -lstdc++fs, which would allow removing src/filesystem/.libs from the LDFLAGS in scripts/testsuite_flags.in, but that can be done at a later date. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_CONFIGURE): Add c++23 directory. * configure: Regenerate. * doc/html/manual/*: Regenerate. * doc/xml/manual/using.xml: Update documentation on linking. * include/std/stacktrace: Remove declarations of libbacktrace APIs. (stacktrace_entry::_S_err_handler, stacktrace_entry::_S_init): Remove. (stacktrace_entry::_Info): New class. (stacktrace_entry::_M_get_info): Use _Info. (__stacktrace_impl): New class. (basic_stacktrace): Derive from __stacktrace_impl. (basic_stacktrace::current): Use __stacktrace_impl::_S_current. * scripts/testsuite_flags.in: Adjust LDFLAGS to find libstdc++exp instead of libstdc++_libbacktrace. * src/Makefile.am (SUBDIRS): Add c++23 directory. * src/Makefile.in: Regenerate. * src/c++20/Makefile.am: Fix comment. * src/c++20/Makefile.in: Regenerate. * src/c++23/Makefile.am: New file. * src/c++23/Makefile.in: New file. * src/c++23/stacktrace.cc: New file with definitions of stacktrace_entry::_Info and __stacktrace_impl members. * src/experimental/Makefile.am: Use LIBADD to include other libraries. * src/experimental/Makefile.in: Regenerate. * src/libbacktrace/Makefile.am: Use noinst_LTLIBRARIES. * src/libbacktrace/Makefile.in: Regenerate. * testsuite/19_diagnostics/stacktrace/current.cc: Adjust dg-options to use -lstdc++exp. * testsuite/19_diagnostics/stacktrace/entry.cc: Likewise. * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise. * testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: Likewise.
2023-09-08libstdc++: Fix unconditional -Werror in libbacktrace directoryAlexey Lapshin2-2/+2
The -Werror flag should depend on the --enable-werror configure option. libstdc++-v3/ChangeLog: * src/libbacktrace/Makefile.am: Remove -Werror. * src/libbacktrace/Makefile.in: Regenerate.
2023-09-07libstdc++: Add autoconf checks for mkdir, chmod, chdir, and getcwdJonathan Wakely3-9/+31
The filesystem code was using these functions without checking for their existence, assuming that any UNIX-like libc with <unistd.h> would always provide them. That's not true for some newlib targets like arm-eabi. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for mkdir, chmod, chdir, and getcwd. * config.h.in: Regenerate. * configure: Regenerate. * src/c++17/fs_ops.cc (create_dir): Use USE_MKDIR macro. (fs::current_path): Use USE_GETCWD and USE_CHDIR macros. (fs::permissions): Use USE_CHMOD macro. * src/filesystem/ops-common.h [FILESYSTEM_IS_WINDOWS] (chmod, mkdir, getcwd, chdir): Define new macros. [FILESYSTEM_IS_WINDOWS] (chmod, mkdir, getcwd, chdir): Use new macros. * src/filesystem/ops.cc (create_dir): Use USE_MKDIR macro. (fs::current_path): Use USE_GETCWD and USE_CHDIR macros. (fs::permissions): Use USE_CHMOD macro.
2023-09-01libstdc++: Use std::string::__resize_and_overwrite in std::filesystemJonathan Wakely2-25/+27
There are a few places in the std::filesystem code that use a string as a buffer for OS APIs to write to. We can use the new extension __resize_and_overwrite to avoid redundant initialization of those buffers. libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::absolute) [FILESYSTEM_IS_WINDOWS]: Use __resize_and_overwrite to fill buffer. (fs::read_symlink) [HAVE_READLINK]: Likewise. * src/filesystem/ops-common.h (get_temp_directory_from_env) [FILESYSTEM_IS_WINDOWS]: Likewise.
2023-09-01libstdc++: Avoid useless dependency on read_symlink from tzdbJonathan Wakely1-0/+4
chrono::tzdb::current_zone uses filesystem::read_symlink, which creates a dependency on the fs_ops.o object in libstdc++.a, which then creates dependencies on several OS functions if --gc-sections isn't used. For more details see PR libstdc++/104167 comment 8 and comment 11. In the cases where that causes linker failures, we probably don't have readlink anyway, so the filesystem::read_symlink call will always fail. Repeat the preprocessor conditions for filesystem::read_symlink in the body of chrono::tzdb::current_zone so that we don't create a dependency on fs_ops.o for a function that will always fail. libstdc++-v3/ChangeLog: * src/c++20/tzdb.cc (tzdb::current_zone): Check configure macros for POSIX readlink before using filesystem::read_symlink.
2023-08-17libstdc++: Replace global std::string objects in tzdb.ccJonathan Wakely1-2/+2
When the library is built with --disable-libstdcxx-dual-abi the only type of std::string supported is the COW string, and the two global std::string objects in tzdb.cc have to allocate memory. I added them thinking they would fit in the SSO string buffer, but that's not the case when the library only uses COW strings. Replace them with string_view objects to avoid any allocations. libstdc++-v3/ChangeLog: * src/c++20/tzdb.cc (tzdata_file, leaps_file): Change type to std::string_view.
2023-08-17libstdc++: Micro-optimize construction of named std::localeJonathan Wakely1-16/+23
This shaves about 100ns off the std::locale constructor for named locales (which is only about 1% of the total time). Using !*s instead of !strcmp(s, "") doesn't make any difference as GCC optimizes that already even at -O1. !strcmp(s, "C") is optimized at -O2 so replacing that with s[0] == 'C' && s[1] == '\0' only matters for the --enable-libstdcxx-debug builds. But !strcmp(s, "POSIX") always makes a call to strcmp at any optimization level. We make that strcmp call, maybe several times, for any locale name except for "C" (which will be matched before we get to the check for "POSIX"). For most targets, locale names begin with a lowercase letter and the only one that begins with 'P' is "POSIX". Replacing !strcmp(s, "POSIX") with s[0] == 'P' && !strcmp(s+1, "OSIX") means that we avoid calling strcmp unless the string really does match "POSIX". Maybe more importantly, I find is_C_locale(s) easier to read than strcmp(s, "C") == 0 || strcmp(s, "POSIX") == 0, and !is_C_locale(s) easier to read than strcmp(s, "C") != 0 && strcmp(s, "POSIX") != 0. libstdc++-v3/ChangeLog: * src/c++98/localename.cc (is_C_locale): New function. (locale::locale(const char*)): Use is_C_locale.
2023-07-30libstdc++: Fix several preprocessor directivesFrançois Dumont3-4/+4
A wrong usage of #define in place of a #error seems to have been replicated at different places in source files. libstdc++-v3/ChangeLog: * src/c++11/compatibility-ldbl-facets-aliases.h: Replace #define with proper #error. * src/c++11/locale-inst-monetary.h: Likewise. * src/c++11/locale-inst-numeric.h: Likewise.
2023-07-19libstdc++: Do not define inaccurate from_chars for _Float128 [PR110077]Jonathan Wakely1-11/+1
I think r14-1431-g7037e7b6e4ac41 was wrong to try to define the _Float128 overload unconditionally. Not all targets need it, so defining the lossy fallback using long double is not useful (and caused an ABI change on Solaris x86). Making the definition depend on USE_STRTOF128_FOR_FROM_CHARS again partially reverts the change for PR 109921, however that should still be fixed because the changes to make USE_STRTOF128_FOR_FROM_CHARS depend on USE_STRTOD_FOR_FROM_CHARS are not reverted. libstdc++-v3/ChangeLog: PR libstdc++/110077 * src/c++17/floating_from_chars.cc (from_chars): Only define _Float128 overload when using __strfromf128.
2023-06-30libstdc++: Fix iostream init for Clang on darwin [PR110432]Jonathan Wakely1-1/+1
The __has_attribute(init_priority) check in <iostream> is true for Clang on darwin, which means that user code including <iostream> thinks the library will initialize the global streams. However, when libstdc++ is built by GCC on darwin, the __has_attribute(init_priority) check is false, which means that the library thinks that user code will do the initialization when <iostream> is included. This means that the initialization is never done. Add an autoconf check so that the header and the library both make their decision based on the static properties of GCC at build time, with a consistent outcome. As a belt and braces check, also do the initialization in <iostream> if the compiler including that header doesn't support the attribute (even if the library also containers the initialization). This might result in redundant initialization done in <iostream>, but ensures the initialization happens somewhere if there's any doubt about the attribute working correctly due to missing linker support. libstdc++-v3/ChangeLog: PR libstdc++/110432 * acinclude.m4 (GLIBCXX_CHECK_INIT_PRIORITY): New. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_INIT_PRIORITY. * include/std/iostream: Use new autoconf macro as well as __has_attribute. * src/c++98/ios_base_init.h: Use new autoconf macro instead of __has_attribute. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2023-06-30libstdc++: Fix unused warning for new variableJonathan Wakely1-3/+3
This newly-introduced variable isn't used on all paths, so add the [[maybe_unused]] attribute. libstdc++-v3/ChangeLog: * src/c++11/random.cc (random_device::_M_init): Add maybe_unused attribute.
2023-06-30libstdc++: Make std::random_device throw more std::system_error [PR105081]Jonathan Wakely1-3/+20
In r14-289-gf9412cedd6c0e7 I made the std::random_device constructor throw std::system_error for unrecognized tokens. But it still throws std::runtime_error for a token such as "rdseed" that is recognized but not supported at runtime by the CPU the program is running on. With this change we throw std::system_error for those cases too. This fixes the following failures on Intel CPUs withour rdseed support: FAIL: 26_numerics/random/random_device/94087.cc execution test FAIL: 26_numerics/random/random_device/cons/token.cc execution test FAIL: 26_numerics/random/random_device/entropy.cc execution test libstdc++-v3/ChangeLog: PR libstdc++/105081 * src/c++11/random.cc (random_device::_M_init): Throw std::system_error when the requested device is a valid token but not available at runtime.
generated by cgit v1.1 at 2025-09-20 22:02:52 +0000