aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/src
AgeCommit message (Collapse)AuthorFilesLines
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.
2023-06-29libstdc++: Fix src/c++20/tzdb.cc for non-constexpr std::mutexJonathan Wakely1-22/+24
Building libstdc++ reportedly fails for targets without lock-free std::atomic<T*> which don't define __GTHREAD_MUTEX_INIT: src/c++20/tzdb.cc:110:21: error: 'constinit' variable 'std::chrono::{anonymous}::list_mutex' does not have a constant initializer src/c++20/tzdb.cc:110:21: error: call to non-'constexpr' function 'std::mutex::mutex()' The solution implemented by this commit is to use a local static mutex when it can't be constinit, so that it's constructed on first use. With this change, we can also simplify the preprocessor logic for defining USE_ATOMIC_SHARED_PTR. It now depends on the same conditions as USE_ATOMIC_LIST_HEAD, so in theory we could have a single macro. Keeping them separate would allow us to replace the use of atomic<shared_ptr<T>> with a mutex if that performs better, without having to give up on the lock-free cache for fast access to the list head. libstdc++-v3/ChangeLog: * src/c++20/tzdb.cc (USE_ATOMIC_SHARED_PTR): Define consistently with USE_ATOMIC_LIST_HEAD. (list_mutex): Replace global object with function. Use local static object when std::mutex constructor isn't constexpr.
2023-06-29libstdc++: Do not use off64_t in calls to copy_file_range [PR110462]Jonathan Wakely1-1/+1
Although the copy_file_range(2) man page shows the arguments as off64_t* that is not portable. For musl there is no off64_t type, as off_t is always 64-bit. Use the loff_t type which is always 64-bit even if off_t isn't. We could just use off_t because the filesystem library is compiled with _FILE_OFFSET_BITS=64, but loff_t is the more correct type for this interface. libstdc++-v3/ChangeLog: PR libstdc++/110462 * acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check that copy_file_range can be called with loff_t* arguments. * configure: Regenerate. * src/filesystem/ops-common.h (copy_file_copy_file_range): Use loff_t for offsets.
2023-06-09libstdc++: Remove duplicate definition of _Float128 std::from_chars [PR110077]Jonathan Wakely1-1/+2
When long double uses IEEE binary128 representation we define the _Float128 overload of std::from_chars inline in <charconv>. My changes in r14-1431-g7037e7b6e4ac41 cause it to also be defined non-inline in the library, leading to an abi-check failure for (at least) sparc and aarch64. Suppress the definition in the library if long double and _Float128 have are both IEEE binary128. libstdc++-v3/ChangeLog: PR libstdc++/110077 * src/c++17/floating_from_chars.cc (from_chars) <_Float128>: Only define if _Float128 and long double have different representations.
2023-06-06libstdc++: Use close-on-exec for file descriptors in filesystem::copy_fileJonathan Wakely1-6/+7
libstdc++-v3/ChangeLog: * src/filesystem/ops-common.h (do_copy_file) [O_CLOEXEC]: Set close-on-exec flag on file descriptors.
2023-06-06libstdc++: Make std::filesystem::copy_file work for procfs [PR108178]Jonathan Wakely1-5/+10
The size reported by stat is always zero for some special files such as those under /proc, which means the current copy_file implementation thinks there is nothing to copy. Instead of trusting the stat value, try to read a character from a streambuf and check for EOF. libstdc++-v3/ChangeLog: PR libstdc++/108178 * src/filesystem/ops-common.h (do_copy_file): Check for empty files by trying to read a character. * testsuite/27_io/filesystem/operations/copy_file_108178.cc: New test.
2023-06-06libstdc++: Use copy_file_range for filesystem::copy_fileJannik Glückert1-0/+56
copy_file_range is a recent-ish syscall for copying files. It is similar to sendfile but allows filesystem-specific optimizations. Common are: Reflinks: BTRFS, XFS, ZFS (does not implement the syscall yet) Server-side copy: NFS, SMB, Ceph If copy_file_range is not available for the given files, fall back to sendfile / userspace copy. libstdc++-v3/ChangeLog: * acinclude.m4 (_GLIBCXX_USE_COPY_FILE_RANGE): Define. * config.h.in: Regenerate. * configure: Regenerate. * src/filesystem/ops-common.h (copy_file_copy_file_range): Define new function. (do_copy_file): Use it. Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
2023-06-06libstdc++: Also use sendfile for big filesJannik Glückert1-29/+44
We were previously only using sendfile for files smaller than 2GB, as sendfile needs to be called repeatedly for files bigger than that. Some quick numbers, copying a 16GB file, average of 10 repetitions: old: real: 13.4s user: 0.14s sys : 7.43s new: real: 8.90s user: 0.00s sys : 3.68s libstdc++-v3/ChangeLog: * acinclude.m4 (_GLIBCXX_HAVE_LSEEK): Define. * config.h.in: Regenerate. * configure: Regenerate. * src/filesystem/ops-common.h (copy_file_sendfile): Define new function for sendfile logic. Loop to support large files. Skip zero-length files. (do_copy_file): Use it. Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
2023-05-31libstdc++: Fix build for targets without _Float128 [PR109921]Jonathan Wakely1-1/+1
My r14-1431-g7037e7b6e4ac41 change caused the _Float128 overload to be compiled unconditionally, by moving the USE_STRTOF128_FOR_FROM_CHARS check into the function body. That function should still only be compiled if the target actually supports _Float128. libstdc++-v3/ChangeLog: PR libstdc++/109921 * src/c++17/floating_from_chars.cc: Check __FLT128_MANT_DIG__ is defined before trying to use _Float128.
2023-05-31libstdc++: Fix preprocessor conditions for std::from_chars [PR109921]Jonathan Wakely1-7/+13
We use the from_chars_strtod function with __strtof128 to read a _Float128 value, but from_chars_strtod is not defined unless uselocale is available. This can lead to compilation failures for some targets, because we try to define the _Flaot128 overload in terms of a non-existing from_chars_strtod function. Only try to use __strtof128 if uselocale is available, otherwise fallback to the long double overload of std::from_chars (which might fallback to the double overload, which should use fast_float). This ensures we always define the full set of overloads, even if they are not always accurate for all values of the wider types. libstdc++-v3/ChangeLog: PR libstdc++/109921 * src/c++17/floating_from_chars.cc (USE_STRTOF128_FOR_FROM_CHARS): Only define when USE_STRTOD_FOR_FROM_CHARS is also defined. (USE_STRTOD_FOR_FROM_CHARS): Do not undefine when long double is binary64. (from_chars(const char*, const char*, double&, chars_format)): Check __LDBL_MANT_DIG__ == __DBL_MANT_DIG__ here. (from_chars(const char*, const char*, _Float128&, chars_format)) Only use from_chars_strtod when USE_STRTOD_FOR_FROM_CHARS is defined, otherwise parse a long double and convert to _Float128.
2023-05-16libstdc++: Disable cacheline alignment for DJGPP [PR109741]Jonathan Wakely1-2/+6
DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=16 which means that globals (and static objects) can't have alignment greater than 16. This causes an error for the locks defined in src/c++11/shared_ptr.cc because we try to align them to the cacheline size, to avoid false sharing. Add a configure check for the increased alignment, and live with false sharing where we can't increase the alignment. libstdc++-v3/ChangeLog: PR libstdc++/109741 * acinclude.m4 (GLIBCXX_CHECK_ALIGNAS_CACHELINE): Define. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_ALIGNAS_CACHELINE. * src/c++11/shared_ptr.cc (__gnu_internal::get_mutex): Do not align lock table if not supported. use __GCC_DESTRUCTIVE_SIZE instead of hardcoded 64.
2023-05-16libstdc++: Stop using _GLIBCXX_USE_C99_STDINT_TR1 in <cstdint>Jonathan Wakely1-2/+2
The _GLIBCXX_USE_C99_STDINT_TR1 macro (and the comments about it in acinclude.m4 and config.h) are misleading when it is also used for <stdint>, not only <tr1/stdint>. It is also wrong, because the configure checks for TR1 use -std=c++98 and a target might define uint32_t etc. for C++11 but not for C++98. Add a separate configure check for the <stdint.h> types using -std=c++11 for the checks. Use the result of that separate check in <cstdint> and most other places that still depend on the macro (many uses of that macro have been removed already). The remaining uses of the STDINT_TR1 macro are really for TR1, or are in the src/c++11/compatibility-*.cc files, where we don't want/need to change the condition they depend on (if those symbols were only exported when <stdint.h> types were available for -std=c++98, then that's the condition we should continue to use for whether to export the compat symbols now). Make similar changes for the related _GLIBCXX_USE_C99_INTTYPES_TR1 and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T_TR1 macros, adding new macros for non-TR1 uses. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_USE_C99): Check for <stdint.h> types in C++11 mode and define _GLIBCXX_USE_C99_STDINT. Check for <inttypes.h> features in C++11 mode and define _GLIBCXX_USE_C99_INTTYPES and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T. * config.h.in: Regenerate. * configure: Regenerate. * doc/doxygen/user.cfg.in (PREDEFINED): Add new macros. * include/bits/chrono.h: Check _GLIBCXX_USE_C99_STDINT instead of _GLIBCXX_USE_C99_STDINT_TR1. * include/c_compatibility/inttypes.h: Check _GLIBCXX_USE_C99_INTTYPES and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T instead of _GLIBCXX_USE_C99_INTTYPES_TR1 and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T_TR1. * include/c_compatibility/stdatomic.h: Check _GLIBCXX_USE_C99_STDINT instead of _GLIBCXX_USE_C99_STDINT_TR1. * include/c_compatibility/stdint.h: Likewise. * include/c_global/cinttypes: Check _GLIBCXX_USE_C99_INTTYPES and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T instead of _GLIBCXX_USE_C99_INTTYPES_TR1 and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T_TR1. * include/c_global/cstdint: Check _GLIBCXX_USE_C99_STDINT instead of _GLIBCXX_USE_C99_STDINT_TR1. * include/std/atomic: Likewise. * src/c++11/cow-stdexcept.cc: Likewise. * testsuite/29_atomics/headers/stdatomic.h/c_compat.cc: Likewise. * testsuite/lib/libstdc++.exp (check_v3_target_cstdint): Likewise.
2023-05-12libstdc++: Remove <random> dependency on _GLIBCXX_USE_C99_STDINT_TR1Jonathan Wakely2-5/+0
Since r9-2028-g8ba7f29e3dd064 we've defined most of <cstdint> unconditionally, including uint_least32_t. This means that all of <random> can be defined unconditionally, which means that std::shuffle and std::ranges::shuffle can be too. libstdc++-v3/ChangeLog: * include/bits/algorithmfwd.h (shuffle): Do not depend on _GLIBCXX_USE_C99_STDINT_TR1. * include/bits/ranges_algo.h (shuffle): Likewise. * include/bits/stl_algo.h (shuffle): Likewise. * include/ext/random: Likewise. * include/ext/throw_allocator.h (random_condition): Likewise. * include/std/random: Likewise. * src/c++11/cow-string-inst.cc: Likewise. * src/c++11/random.cc: Likewise.
2023-05-11libstdc++: Use RAII types in strtod-based std::from_chars implementationJonathan Wakely1-19/+69
This adds auto_locale and auto_ferounding types to use RAII for changing and restoring the local and floating-point environment when using strtod to implement std::from_chars. The destructors for the RAII objects run slightly later than the previous statements that restored the locale/fenv, but the differences are just some trivial assignments and an isinf call. Reviewed-by: Patrick Palka <ppalka@redhat.com> libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc [USE_STRTOD_FOR_FROM_CHARS] (auto_locale, auto_ferounding): New class types. (from_chars_impl): Use auto_locale and auto_ferounding.
2023-05-03libstdc++: Fix up abi.exp FAILs on powerpc64le-linuxJakub Jelinek2-0/+24
This is an ABI problem on powerpc64le-linux, introduced in 13.1. When libstdc++ is configured against old glibc, the _ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31 _ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31 _ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31 _ZSt8to_charsPcS_DF128_St12chars_formati@@GLIBCXX_3.4.31 symbols are exported from the library, while when it is configured against new enough glibc, those symbols aren't exported and we export instead _ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29 _ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29 _ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29 _ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29 together with various other @@GLIBCXX_IEEE128_3.4.{29,30,31} and @@CXXABI_IEEE128_1.3.13 symbols. The idea was that those *IEEE128* symbol versions (similarly to *LDBL* symbol versions) are optional (but if it appears, all symbols from it up to the version of the library appears), but the base appears always. My _Float128 from_chars/to_chars changes unfortunately broke this. I believe nothing really uses those symbols if libstdc++ has been configured against old glibc, so if 13.1 wasn't already released, it might be best to make sure they aren't exported on powerpc64le-linux. But as they were exported, I think the best resolution for this ABI difference is to add those 4 symbols as aliases to the GLIBCXX_IEEE128_3.4.29 *u9__ieee128* symbols, which the following patch does. 2023-05-03 Jakub Jelinek <jakub@redhat.com> * src/c++17/floating_from_chars.cc (_ZSt10from_charsPKcS0_RDF128_St12chars_format): New alias to _ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format. * src/c++17/floating_to_chars.cc (_ZSt8to_charsPcS_DF128_): New alias to _ZSt8to_charsPcS_u9__ieee128. (_ZSt8to_charsPcS_DF128_St12chars_format): New alias to _ZSt8to_charsPcS_u9__ieee128St12chars_format. (_ZSt8to_charsPcS_DF128_St12chars_formati): New alias to _ZSt8to_charsPcS_u9__ieee128St12chars_formati. * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Updated.
2023-05-02ibstdc++: Shut up -Wattribute-alias warning [PR109694]Jakub Jelinek1-0/+2
I've followed what other files do, using attribute alias with not really matching function type (after all, it isn't really possible when it is a constructor), but seems I've missed it warns: ../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’ alias between functions of incompatible types ‘void()’ and ‘void +(std::ios_base::Init::)()’ [-Wattribute-alias=] 203 | void ios_base_library_init (void) | ^~~~~~~~~~~~~~~~~~~~~ ../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here 78 | ios_base::Init::Init() | ^~~~~~~~ The PR talks about clang++ warning there (which I think isn't really supported, libstdc++ sources ought to be built by GCC), but it warns when built with GCC too. The following patch fixes it by doing what other libstdc++ sources do in those cases. 2023-05-02 Jakub Jelinek <jakub@redhat.com> PR libstdc++/109694 * src/c++98/ios_init.cc: Add #pragma GCC diagnostic ignored for -Wattribute-alias.
2023-04-28libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc ↵Jakub Jelinek1-0/+5
13.2+ libstdc++.so.6 [PR108969] GCC used to emit an instance of an empty ios_base::Init class in every TU which included <iostream> to ensure it is std::cout etc. is initialized, but thanks to Patrick work on some targets (which have init_priority attribute support) it is now initialized only inside of libstdc++.so.6/libstdc++.a. This causes a problem if people do something that has never been supported, try to run GCC 13 compiled C++ code against GCC 12 or earlier libstdc++.so.6 - std::cout etc. are then never initialized because code including <iostream> expects the library to initialize it and the library expects code including <iostream> to do that. The following patch is second attempt to make this work cheaply as the earlier attempt of aliasing the std::cout etc. symbols with another symbol version didn't work out due to copy relocation breaking the aliases appart. The patch forces just a _ZSt21ios_base_library_initv undefined symbol into all *.o files which include <iostream> and while there is no runtime relocation against that, it seems to enforce the right version of libstdc++.so.6. /home/jakub/src/gcc/obj08i/usr/local/ is the install directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/ is builddir of trunk without this patch, system g++ is GCC 12.1.1. $ cat /tmp/hw.C #include <iostream> int main () { std::cout << "Hello, world!" << std::endl; } $ cd /home/jakub/src/gcc/obj08i/usr/local/bin $ ./g++ -o /tmp/hw /tmp/hw.C $ readelf -Wa /tmp/hw 2>/dev/null | grep initv 4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4) 71: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 $ /tmp/hw /tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw) $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw Hello, world! $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw /tmp/hw: /home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw) $ g++ -o /tmp/hw /tmp/hw.C $ /tmp/hw Hello, world! $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw Hello, world! $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw Hello, world! On sparc-sun-solaris2.11 one I've actually checked a version which had defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but init_priority attribute doesn't seem to be supported there and so I couldn't actually test how this works there. Using gas and Sun ld, Rainer, does one need to use gas + gld for init_priority or something else? 2023-04-28 Jakub Jelinek <jakub@redhat.com> PR libstdc++/108969 * config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export _ZSt21ios_base_library_initv. * testsuite/util/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.32 symver and make it the latestp. * src/c++98/ios_init.cc (ios_base_library_init): New alias. * acinclude.m4 (libtool_VERSION): Change to 6:32:0. * include/std/iostream: If init_priority attribute is supported and _GLIBCXX_SYMVER_GNU, force undefined _ZSt21ios_base_library_initv symbol into the object. * configure: Regenerated.
2023-04-27libstdc++: Make std::random_device throw std::system_error [PR105081]Jonathan Wakely1-6/+12
This changes std::random_device constructors to throw std::system_error (with EINVAL as the error code) when the constructor argument is invalid. We can also throw std::system_error when read(2) fails so that the exception includes the additional information provided by errno. As noted in the PR, this is consistent with libc++, and doesn't break any existing code which catches std::runtime_error, because those handlers will still catch std::system_error. libstdc++-v3/ChangeLog: PR libstdc++/105081 * src/c++11/random.cc (__throw_syserr): New function. (random_device::_M_init, random_device::_M_init_pretr1): Use new function for bad tokens. (random_device::_M_getval): Use new function for read errors. * testsuite/util/testsuite_random.h (random_device_available): Change catch handler to use std::system_error.
2023-04-19Revert "libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver ↵Jonathan Wakely5-34/+19
[PR108969]" This reverts commit b7c54e3f48086c29179f7765a35c381de5109a0a. libstdc++-v3/ChangeLog: * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: * config/abi/post/i486-linux-gnu/baseline_symbols.txt: * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: * config/abi/pre/gnu.ver: * src/Makefile.am: * src/Makefile.in: * src/c++98/Makefile.am: * src/c++98/Makefile.in: * src/c++98/globals_io.cc (defined): (_GLIBCXX_IO_GLOBAL):
generated by cgit v1.1 at 2025-07-13 06:35:31 +0000