- Jan 08, 2025
-
-
Jonathan Wakely authored
The std-clib.cc module definition file assumes that all names are available unconditionally, but that's not true for all targets. Use the same preprocessor conditions as are present in the <cxxx> headers. A similar change is needed in std.cc.in for the <chrono> features that depend on the SSO std::string, guarded with a __cpp_lib_chrono value indicating full C++20 support. The conditions for <cmath> are omitted from this change, as there are a large number of them. That probably needs to be fixed. libstdc++-v3/ChangeLog: PR libstdc++/118177 * src/c++23/std-clib.cc.in: Use preprocessor conditions for names which are not always defined. * src/c++23/std.cc.in: Likewise.
-
Jonathan Wakely authored
The current check for negative times (i.e. before the epoch) only checks for a negative number of seconds. For a time 1ms before the epoch the seconds part will be zero, but the futex syscall will still fail with an EINVAL error. Extend the check to handle this case. This change adds a redundant check in the headers too, so that we avoid even calling into the library for negative times. Both checks can be marked [[unlikely]]. The check in the headers avoids the cost of splitting the time into seconds and nanoseconds and then making a PLT call. The check inside the library matches where we were checking already, and fixes existing binaries that were compiled against older headers but use a newer libstdc++.so.6 at runtime. libstdc++-v3/ChangeLog: PR libstdc++/118093 * include/bits/atomic_futex.h (_M_load_and_test_until_impl): Return false for times before the epoch. * src/c++11/futex.cc (_M_futex_wait_until): Extend check for negative times to check for subsecond times. Add unlikely attribute. (_M_futex_wait_until_steady): Likewise. * testsuite/30_threads/future/members/118093.cc: New test.
-
- Jan 02, 2025
-
-
Jakub Jelinek authored
-
Jakub Jelinek authored
-
- Dec 19, 2024
-
-
Patrick Palka authored
This implements the C++23 container adaptors std::flat_set and std::flat_multiset from P1222R4. The implementation is essentially an simpler and pared down version of std::flat_map. libstdc++-v3/ChangeLog: * include/Makefile.am: Add new header <flat_set>. * include/Makefile.in: Regenerate. * include/bits/version.def (__cpp_flat_set): Define. * include/bits/version.h: Regenerate * include/precompiled/stdc++.h: Include <flat_set>. * include/std/flat_set: New file. * src/c++23/std.cc.in: Export <flat_set>. * testsuite/23_containers/flat_multiset/1.cc: New test. * testsuite/23_containers/flat_set/1.cc: New test. Co-authored-by:
Jonathan Wakely <jwakely@redhat.com> Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
Patrick Palka authored
This implements the C++23 container adaptors std::flat_map and std::flat_multimap from P0429R9. The implementation is shared as much as possible between the two adaptors via a common base class that's parameterized according to key uniqueness. libstdc++-v3/ChangeLog: * include/Makefile.am: Add new header <flat_map>. * include/Makefile.in: Regenerate. * include/bits/alloc_traits.h (__not_allocator_like): New concept. * include/bits/stl_function.h (__transparent_comparator): Likewise. * include/bits/stl_iterator_base_types.h (__has_input_iter_cat): Likewise. * include/bits/uses_allocator.h (__allocator_for): Likewise. * include/bits/utility.h (sorted_unique_t): Define for C++23. (sorted_unique): Likewise. (sorted_equivalent_t): Likewise. (sorted_equivalent): Likewise. * include/bits/version.def (flat_map): Define. * include/bits/version.h: Regenerate. * include/precompiled/stdc++.h: Include <flat_map>. * include/std/flat_map: New file. * src/c++23/std.cc.in: Export <flat_map>. * testsuite/23_containers/flat_map/1.cc: New test. * testsuite/23_containers/flat_multimap/1.cc: New test. Co-authored-by:
Jonathan Wakely <jwakely@redhat.com> Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
- Dec 12, 2024
-
-
Jonathan Wakely authored
libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc: Fix typo in comment.
-
- Dec 02, 2024
-
-
Jonathan Wakely authored
This avoids some warnings when building the std module. libstdc++-v3/ChangeLog: * src/c++23/std.cc.in: Disable deprecated warnings when exporting std::rel_ops members.
-
- Nov 27, 2024
-
-
Patrick Palka authored
This declares the range adaptor pipe operators a friend of the _RangeAdaptorClosure base class so that the std module doesn't need to export them for ADL to find them. Note that we deliberately don't define these pipe operators as hidden friends, see r14-3293-g4a6f3676e7dd9e. libstdc++-v3/ChangeLog: * include/std/ranges (views::__adaptor::_RangeAdaptorClosure): Befriend both operator| overloads. * src/c++23/std.cc.in: Don't export views::__adaptor::operator|. Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
Jason Merrill authored
Some tests were failing due to the exported using declaration of iter_move conflicting with friend declarations; the exported using needs to be in the inline namespace, like the customization point itself, rather than std::ranges. Also add a few missing exports. Some tests failed to find some operators defined in implementation-detail namespaces; this exports them as well, but as previously discussed it's probably preferable to make those operators friends so ADL can find them that way. libstdc++-v3/ChangeLog: * src/c++23/std.cc.in: Fix iter_move/swap. Add fold_left_first, to, concat, and some operators.
-
- Nov 26, 2024
-
-
Jonathan Wakely authored
As described in PR 117630 the cow-stdexcept.cc file pulls in symbols from system_error.cc, which are not actually needed there. Moving the definition of error_category::_M_message to a separate file should solve it. libstdc++-v3/ChangeLog: PR libstdc++/117630 * src/c++11/Makefile.am: Add new file. * src/c++11/Makefile.in: Regnerate. * src/c++11/cow-stdexcept.cc (error_category::_M_message): Move member function definition to ... * src/c++11/cow-system_error.cc: New file.
-
- Nov 19, 2024
-
-
Jason Merrill authored
Standard JSON doesn't have comments, and it seems this file needs to be conforming, not the common JSON-with-comments dialect. libstdc++-v3/ChangeLog: * src/c++23/libstdc++.modules.json.in: Remove C++ comment.
-
- Nov 17, 2024
-
-
Jason Merrill authored
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.
-
- Nov 06, 2024
-
-
Jonathan Wakely authored
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.
-
- Sep 22, 2024
-
-
Jonathan Wakely authored
libstdc++-v3/ChangeLog: * src/c++11/cxx11-ios_failure.cc (__iosfail_type_info): Unhide the three-arg overload of __do_upcast.
-
- Sep 10, 2024
-
-
Jonathan Wakely authored
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.
-
- Sep 03, 2024
-
-
Jonathan Wakely authored
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.
-
- Aug 23, 2024
-
-
Jonathan Wakely authored
libstdc++-v3/ChangeLog: * src/c++11/debug.cc: Replace throw() with noexcept.
-
- Aug 21, 2024
-
-
Jonathan Wakely authored
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.
-
- Jul 31, 2024
-
-
Jonathan Wakely authored
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.
-
Jonathan Wakely authored
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.
-
Jonathan Wakely authored
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.
-
- Jul 30, 2024
-
-
Jonathan Wakely authored
libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc: Fix file name in comment.
-
Jonathan Wakely authored
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.
-
Lennox Shou Hao Ho authored
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>
-
- Jul 23, 2024
-
-
Jonathan Wakely authored
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.
-
Detlef Vollmann authored
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.
-
- Jul 10, 2024
-
-
Jonathan Wakely authored
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.
-
- Jun 28, 2024
-
-
Jonathan Wakely authored
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.
-
- Jun 26, 2024
-
-
Jonathan Wakely authored
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.
-
- May 29, 2024
-
-
Rainer Orth authored
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.
-
- May 22, 2024
-
-
Jonathan Wakely authored
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.
-
- May 14, 2024
-
-
Jonathan Wakely authored
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.
-
- May 07, 2024
-
-
Rainer Orth authored
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.
-
- Apr 19, 2024
-
-
Jonathan Wakely authored
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.
-
- Apr 18, 2024
-
-
Alexandre Oliva authored
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.
-
- Apr 15, 2024
-
-
Jonathan Wakely authored
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.
-
- Apr 10, 2024
-
-
Jonathan Wakely authored
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.
-
- Mar 07, 2024
-
-
Jonathan Wakely authored
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.
-
- Feb 15, 2024
-
-
Jonathan Wakely authored
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.
-