aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/src
AgeCommit message (Collapse)AuthorFilesLines
2021-02-24libstdc++: Fix order of arguments to sprintf [PR 99261]Jonathan Wakely1-2/+2
libstdc++-v3/ChangeLog: PR libstdc++/99261 * src/c++17/floating_to_chars.cc (sprintf_ld): Add extra args before value to be printed.
2021-02-24libstdc++: Fix __floating_to_chars_precision for __float128Patrick Palka1-1/+1
The code path in __floating_to_chars_precision for handling long double by going through printf now also handles __float128, so the condition that guards this code path needs to get updated accordingly. libstdc++-v3/ChangeLog: * src/c++17/floating_to_chars.cc (__floating_to_chars_precision): Relax the condition that guards the printf code path to accept F128_type as well as long double.
2021-02-24libstdc++: Define std::to_chars overloads for __ieee128 [PR 98389]Jonathan Wakely3-113/+195
This adds overloads of std::to_chars for powerpc64's __ieee128, so that std::to_chars can be used for long double when -mabi=ieeelongdouble is in used. Eventually we'll want to extend these new overloads to work for __float128 on all targets that support that type. For now, we're only doing it for powerpc64 when the new long double type is supported in parallel to the old long double type. Additionally the existing std::to_chars overloads for long double are given the right symbol version, resolving PR libstdc++/98389. libstdc++-v3/ChangeLog: PR libstdc++/98389 * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Do not match to_chars symbols for long double arguments mangled as 'g'. * config/os/gnu-linux/ldbl-extra.ver: Likewise. * config/os/gnu-linux/ldbl-ieee128-extra.ver: Likewise. * src/c++17/Makefile.am [GLIBCXX_LDBL_ALT128_COMPAT_TRUE]: Use -mabi=ibmlongdouble for floating_to_chars.cc. * src/c++17/Makefile.in: Regenerate. * src/c++17/floating_to_chars.cc (floating_type_traits_binary128): New type defining type traits of IEEE binary128 format. (floating_type_traits<__float128>): Define specialization. (floating_type_traits<long double>): Define in terms of floating_type_traits_binary128 when appropriate. (floating_to_shortest_scientific): Handle __float128. (sprintf_ld): New function template for printing a long double or __ieee128 value using sprintf. (__floating_to_chars_shortest, __floating_to_chars_precision): Use sprintf_ld. (to_chars): Define overloads for __float128.
2021-02-22libstdc++: Fix endianness issue with IBM long double [PR98384]Patrick Palka1-4/+4
The code in std::to_chars for extracting the high- and low-order parts of an IBM long double value does the right thing on powerpc64le, but not on powerpc64be. This patch makes the extraction endian-agnostic, which fixes the execution FAIL of to_chars/long_double.cc on powerpc64be. libstdc++-v3/ChangeLog: PR libstdc++/98384 * src/c++17/floating_to_chars.cc (get_ieee_repr): Extract the high- and low-order parts from an IBM long double value in an endian-agnostic way.
2021-02-12libstdc++: Re-enable workaround for _wstat64 bug, again [PR 88881]Jonathan Wakely1-2/+0
I forgot that the workaround is present in both filesystem::status and filesystem::symlink_status. This restores it in the latter. libstdc++-v3/ChangeLog: PR libstdc++/88881 * src/c++17/fs_ops.cc (fs::symlink_status): Re-enable workaround.
2021-02-12libstdc++: Fix filesystem::rename on Windows [PR 98985]Jonathan Wakely2-1/+40
The _wrename function won't overwrite an existing file, so use MoveFileEx instead. That allows renaming directories over files, which POSIX doesn't allow, so check for that case explicitly and report an error. Also document the deviation from the expected behaviour, and add a test for filesystem::rename which was previously missing. The Filesystem TS experimental::filesystem::rename doesn't have that extra code to handle directories correctly, so the relevant parts of the new test are not run on Windows. libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2014.xml: Document implementation specific properties of std::experimental::filesystem::rename. * doc/xml/manual/status_cxx2017.xml: Document implementation specific properties of std::filesystem::rename. * doc/html/*: Regenerate. * src/c++17/fs_ops.cc (fs::rename): Implement correct behaviour for directories on Windows. * src/filesystem/ops-common.h (__gnu_posix::rename): Use MoveFileExW on Windows. * testsuite/27_io/filesystem/operations/rename.cc: New test. * testsuite/experimental/filesystem/operations/rename.cc: New test.
2021-02-12libstdc++: Add unused attributes to shared_ptr functionsJonathan Wakely1-1/+1
This avoids some warnings when building with -fno-rtti because the function parameters are only used when RTTI is enabled. libstdc++-v3/ChangeLog: * include/bits/shared_ptr_base.h (__shared_ptr::_M_get_deleter): Add unused attribute to parameter. * src/c++11/shared_ptr.cc (_Sp_make_shared_tag::_S_eq): Likewise.
2021-02-12libstdc++: Fix bootstrap with -fno-rtti [PR 99077]Jonathan Wakely1-6/+5
When libstdc++ is built without RTTI the __ios_failure type is just an alias for std::ios_failure, so trying to construct it from an int won't compile. This changes the RTTI-enabled __ios_failure type to have the same constructor parameters as std::ios_failure, so that the constructor takes the same arguments whether RTTI is enabled or not. The __throw_ios_failure function now constructs the error_code, instead of the __ios_failure constructor. As a drive-by fix that error_code is constructed with std::generic_category() not std::system_category(), because the int comes from errno which corresponds to the generic category. libstdc++-v3/ChangeLog: PR libstdc++/99077 * src/c++11/cxx11-ios_failure.cc (__ios_failure(const char*, int)): Change int parameter to error_code, to match std::ios_failure. (__throw_ios_failure(const char*, int)): Construct error_code from int parameter.
2021-02-10libstdc++: Re-enable workaround for _wstat64 bug [PR 88881]Jonathan Wakely1-2/+0
This wasn't fixed upstream for mingw-w64 so we still need the workaround. libstdc++-v3/ChangeLog: PR libstdc++/88881 * src/c++17/fs_ops.cc (fs::status): Re-enable workaround.
2021-02-10libstdc++: Use correct error category for Windows error codesJonathan Wakely2-6/+6
When the result of GetLastError() is stored in a std::error_code it should use std::system_category(), not std::generic_category() that is used for POSIX errno values. libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::create_hard_link, fs::equivalent) (fs::remove): Use std::system_category() for error codes from GetLastError(). * src/filesystem/ops.cc (fs::create_hard_link, fs::remove): Likewise.
2021-02-09libstdc++: Fix build failure for targets without unistd.hVladimir Vishnevsky1-1/+1
The patch fixes build issues occurring if build parameter "--enable-cstdio=stdio_pure" is specified and no unistd.h is present in the environment. libstdc++-v3/ChangeLog: * include/ext/stdio_sync_filebuf.h: Remove unused <unistd.h>. * src/c++17/fs_ops.cc (fs::permissions): Qualify mode_t.
2021-01-21libstdc++: Regenerate Makefile.inJonathan Wakely1-2/+2
This removes a trivial whitespace difference between the currently committed file and the one regenerated by autotools. libstdc++-v3/ChangeLog: * src/c++17/Makefile.in: Regenerate.
2021-01-18libstd++: : Add workaround for as Error: file number less than one error ↵Jakub Jelinek2-4/+4
[PR98708] As mentioned in the PR, since the switch to DWARF5 by default instead of DWARF4, gcc fails to build when configured against recent binutils. The problem is that cxx11-ios_failure* is built in separate steps, -S compilation (with -g -O2) followed by some sed and followed by -c -g -O2 -g0 assembly. When gcc is configured against recent binutils and DWARF5 is the default, we emit .file 0 "..." directive on which the assembler then fails (unless --gdwarf-5 is passed to it, but we don't want that generally because on the other side older assemblers don't like -g* passed to it when invoked on *.s file with compiler generated debug info. I hope the bug will be fixed soon on the binutils side, but it would be nice to have a workaround. The following patch is one of the possibilities, another one is to do that but add configure check for whether it is needed, essentially echo 'int main () { return 0; }' > conftest.c ${CXX} ${CXXFLAGS} -g -O2 -S conftest.c -o conftest.s ${CXX} ${CXXFLAGS} -g -O2 -g0 -c conftest.s -o conftest.o and if the last command fails, we need that -gno-as-loc-support. Or yet another option would be I think do a different check, whether ${CXX} ${CXXFLAGS} -g -O2 -S conftest.c -o conftest.s ${CXX} ${CXXFLAGS} -g -O2 -c conftest.s -o conftest.o works and if yes, don't add the -g0 to cxx11-ios_failure*.s assembly. 2021-01-18 Jakub Jelinek <jakub@redhat.com> PR debug/98708 * src/c++11/Makefile.am (cxx11-ios_failure-lt.s, cxx11-ios_failure.s): Compile with -gno-as-loc-support. * src/c++11/Makefile.in: Regenerated.
2021-01-14libstdc++: Implement N3644 for _GLIBCXX_DEBUG iteratorsFrançois Dumont1-4/+1
libstdc++-v3/ChangeLog: PR libstdc++/98466 * include/bits/hashtable_policy.h (_Node_iterator_base()): Set _M_cur to nullptr. (_Node_iterator()): Make default. (_Node_const_iterator()): Make default. * include/debug/macros.h (__glibcxx_check_erae_range_after): Add _M_singular iterator checks. * include/debug/safe_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Accept if both iterator are value initialized. * include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Likewise. * include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_valid_range): Add _M_singular checks on input iterators. * src/c++11/debug.cc (_Safe_iterator_base::_M_can_compare): Remove _M_singular checks. * testsuite/23_containers/deque/debug/98466.cc: New test. * testsuite/23_containers/unordered_map/debug/98466.cc: New test.
2021-01-04Update copyright years.Jakub Jelinek130-130/+130
2020-12-21libstdc++: Disable floating-point std::to_chars on unsupported targetsPatrick Palka1-4/+6
This patch conditionally disables the floating-point std::to_chars implementation on targets whose float and double aren't IEEE binary32 and binary64, until a proper fallback can be added for such targets. This fixes a bootstrap failure on non-IEEE-754 FP targets such as vax-netbsdelf. The new preprocessor tests in c++config that detect the binary32 and binary64 formats were copied from gcc/testsuite/gcc.dg/float-exact-1.c. libstdc++-v3/ChangeLog: * include/bits/c++config (_GLIBCXX_FLOAT_IS_IEEE_BINARY_32): Define this macro. (_GLIBCXX_DOUBLE_IS_IEEE_BINARY_64): Likewise. * include/std/charconv (to_chars): Use these macros to conditionally hide the overloads for floating-point types. * src/c++17/floating_to_chars.cc: Use the macros to conditionally disable this file. (floating_type_traits<float>): Remove redundant static assert. (floating_type_traits<double>): Likewise. * testsuite/20_util/to_chars/double.cc: Run this test only on ieee-floats effective targets. * testsuite/20_util/to_chars/float.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise. * testsuite/lib/libstdc++.exp (check_effective_target_ieee-floats): Define new proc for detecting whether float and double have the IEEE binary32 and binary64 formats.
2020-12-18libstdc++: Fix mistake in PR98374 change [PR98377]Patrick Palka1-1/+1
The #ifdef RADIXCHAR directive should be moved one line up so that it also guards the outer if statement, or else when RADIXCHAR is not defined the outer if statement will end up nonsensically guarding the declaration of output_length_upper_bound a few lines below it. libstdc++-v3/ChangeLog: PR libstdc++/98377 * src/c++17/floating_to_chars.cc (__floating_to_chars_precision): Fix mistake.
2020-12-18libstdc++: Fix build failure on AArch64 ILP32 [PR98370]Patrick Palka1-1/+1
This should fix a build failure on AArch64 ILP32 due to int32_t mapping to long int instead of int on this platform, which causes type deduction to fail in the below call to std::max as reported in the PR. libstdc++-v3/ChangeLog: PR libstdc++/98370 * src/c++17/floating_to_chars.cc (__floating_to_chars_shortest): Provide explicit template arguments to the call to std::max.
2020-12-18libstdc++: Fix build failure due to missing <langinfo.h> [PR98374]Patrick Palka1-1/+5
This should fix a build failure on Windows which lacks <langinfo.h>, from which we use nl_langinfo() to obtain the radix character of the current locale. (We can't use the more portable localeconv() from <clocale> to obtain the radix character of the current locale here because it's not thread-safe, unfortunately.) This change means that on Windows and other such platforms, we'll just always assume the radix character used by printf is '.' when formatting a long double through it. libstdc++-v3/ChangeLog: PR libstdc++/98374 * src/c++17/floating_to_chars.cc: Guard include of <langinfo.h> with __has_include. (__floating_to_chars_precision) [!defined(RADIXCHAR)]: Don't attempt to obtain the radix character of the current locale, just assume it's '.'.
2020-12-18libstdc++: Check FE_TONEAREST is defined before using itPatrick Palka2-6/+6
We need to test that FE_TONEAREST is defined before we may use it along with fegetround/fesetround to adjust the floating-point rounding mode. This fixes a build failure with older versions of newlib. libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (from_chars_impl) [!defined(FE_TONEAREST)]: Don't adjust the rounding mode. * src/c++17/floating_to_chars.cc (__floating_to_chars_precision): Likewise.
2020-12-17libstdc++: Add floating-point std::to_chars implementationPatrick Palka3-1/+1566
This implements the floating-point std::to_chars overloads for float, double and long double. We use the Ryu library to compute the shortest round-trippable fixed and scientific forms for float, double and long double. We also use Ryu for performing explicit-precision fixed and scientific formatting for float and double. For explicit-precision formatting for long double we fall back to using printf. Hexadecimal formatting for float, double and long double is implemented from scratch. The supported long double binary formats are binary64, binary80 (x86 80-bit extended precision), binary128 and ibm128. Much of the complexity of the implementation is in computing the exact output length before handing it off to Ryu (which doesn't do bounds checking). In some cases it's hard to compute the output length beforehand, so in these cases we instead compute an upper bound on the output length and use a sufficiently-sized intermediate buffer only if necessary. Another source of complexity is in the general-with-precision formatting mode, where we need to do zero-trimming of the string returned by Ryu, and where we also take care to avoid having to format the number through Ryu a second time when the general formatting mode resolves to fixed (which we determine by doing a scientific formatting first and inspecting the scientific exponent). We avoid going through Ryu twice by instead transforming the scientific form to the corresponding fixed form via in-place string manipulation. This implementation is non-conforming in a couple of ways: 1. For the shortest hexadecimal formatting, we currently follow the Microsoft implementation's decision to be consistent with the output of printf's '%a' specifier at the expense of sometimes not printing the shortest representation. For example, the shortest hex form for the number 1.08p+0 is 2.1p-1, but we output the former instead of the latter, as does printf. 2. The Ryu routine generic_binary_to_decimal that we use for performing shortest formatting for large floating point types is implemented using the __int128 type, but some targets with a large long double type lack __int128 (e.g. i686), so we can't perform shortest formatting of long double on such targets through Ryu. As a temporary stopgap this patch makes the long double to_chars overloads just dispatch to the double overloads on these targets, which means we lose precision in the output. (We could potentially fix this by writing a specialized version of Ryu's generic_binary_to_decimal routine that uses uint64_t instead of __int128.) [Though I wonder if there's a better way to work around the lack of __int128 on i686 specifically?] 3. Our shortest formatting for __ibm128 doesn't guarantee the round-trip property if the difference between the high- and low-order exponent is large. This is because we treat __ibm128 as if it has a contiguous 105-bit mantissa by merging the mantissas of the high- and low-order parts (using code extracted from glibc), so we potentially lose precision from the low-order part. This seems to be consistent with how glibc printf formats __ibm128. libstdc++-v3/ChangeLog: * config/abi/pre/gnu.ver: Add new exports. * include/std/charconv (to_chars): Declare the floating-point overloads for float, double and long double. * src/c++17/Makefile.am (sources): Add floating_to_chars.cc. * src/c++17/Makefile.in: Regenerate. * src/c++17/floating_to_chars.cc: New file. (to_chars): Define for float, double and long double. * testsuite/20_util/to_chars/long_double.cc: New test.
2020-12-17libstdc++: Apply modifications to our local copy of RyuPatrick Palka8-236/+45
This performs the following modifications to our local copy of Ryu in order to make it more readily usable for our std::to_chars implementation: * Remove all #includes * Remove copy_special_str routines * Adjust the exponent formatting to match printf * Remove some functions we're not going to use * Add an out-parameter to d2exp_buffered_n for the scientific exponent * Store the sign bit inside struct floating_decimal_[32|64] * Rename [df]2s_buffered_n and change their return type * Make generic_binary_to_decimal take the bit representation in parts libstdc++-v3/ChangeLog: * src/c++17/ryu/common.h, src/c++17/ryu/d2fixed.c, src/c++17/ryu/d2fixed_full_table.h, src/c++17/ryu/d2s.c, src/c++17/ryu/d2s_intrinsics.h, src/c++17/ryu/f2s.c, src/c++17/ryu/f2s_intrinsics.h, src/c++17/ryu/generic_128.c: Apply local modifications.
2020-12-17libstdc++: Import parts of the Ryu libraryPatrick Palka13-0/+8024
This imports the source files from the Ryu library that define d2s_buffered_n, f2s_buffered_n, d2fixed_buffered_n, d2exp_buffered_n and generic_binary_to_decimal, which we're going to use as the base of our std::to_chars implementation. libstdc++-v3/ChangeLog: * src/c++17/ryu/MERGE: New file. * src/c++17/ryu/common.h, src/c++17/ryu/d2fixed.c, src/c++17/ryu/d2fixed_full_table.h, src/c++17/ryu/d2s.c, src/c++17/ryu/d2s_full_table.h, src/c++17/ryu/d2s_intrinsics.h, src/c++17/ryu/digit_table.h, src/c++17/ryu/f2s.c, src/c++17/ryu/f2s_intrinsics.h, src/c++17/ryu/generic_128.c, src/c++17/ryu/generic_128.h, src/c++17/ryu/ryu_generic_128.h: Import these files from the Ryu library.
2020-12-17libstdc++: Fix -Wunused warningJonathan Wakely1-1/+2
As noted in PR 66146 comment 35, there is a new warning in the new std::call_once implementation. libstdc++-v3/ChangeLog: * src/c++11/mutex.cc (std::once_flag::_M_finish): Add maybe_unused attribute to variable used in assertion.
2020-12-16libstdc++: Add C++ runtime support for new 128-bit long double formatJonathan Wakely21-268/+885
This adds support for the new __ieee128 long double format on powerpc64le targets. Most of the complexity comes from wanting a single libstdc++.so library that contains the symbols needed by code compiled with both -mabi=ibmlongdouble and -mabi=ieeelongdouble (and not forgetting -mlong-double-64 as well!) In a few places this just requires an extra overload, for example std::from_chars has to be overloaded for both forms of long double. That can be done in a single translation unit that defines overloads for 'long double' and also '__ieee128', so that user code including <charconv> will be able to link to a definition for either type of long double. Those are the easy cases. The difficult parts are (as for the std::string ABI transition) the I/O and locale facets. In order to be able to write either form of long double to an ostream such as std::cout we need the locale to contain a std::num_put facet that can handle both forms. The same approach is taken as was already done for supporting 64-bit long double and 128-bit long double: adding extra overloads of do_put to the facet class. On targets where the new long double code is enabled, the facets that are registered in the locale at program startup have additional overloads so that they can work with any long double type. Where this fails to work is if user code installs its own facet, which will probably not have the additional overloads and so will only be able to output one or the other type. In practice the number of users expecting to be able to use their own locale facets in code using a mix of -mabi=ibmlongdouble and -mabi=ieeelongdouble is probably close to zero. libstdc++-v3/ChangeLog: * Makefile.in: Regenerate. * config.h.in: Regenerate. * config/abi/pre/gnu.ver: Make patterns less greedy. * config/os/gnu-linux/ldbl-ieee128-extra.ver: New file with patterns for IEEE128 long double symbols. * configure: Regenerate. * configure.ac: Enable alternative 128-bit long double format on powerpc64*-*-linux*. * doc/Makefile.in: Regenerate. * fragment.am: Regenerate. * include/Makefile.am: Set _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT. * include/Makefile.in: Regenerate. * include/bits/c++config: Define inline namespace for new long double symbols. Don't define _GLIBCXX_USE_FLOAT128 when it's the same type as long double. * include/bits/locale_classes.h [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT] (locale::_Impl::_M_init_extra_ldbl128): Declare new member function. * include/bits/locale_facets.h (_GLIBCXX_NUM_FACETS): Simplify by only counting narrow character facets. (_GLIBCXX_NUM_CXX11_FACETS): Likewise. (_GLIBCXX_NUM_LBDL_ALT128_FACETS): New. [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT] (num_get::__do_get): Define vtable placeholder for __ibm128 long double type. [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__] (num_get::__do_get): Declare vtable placeholder for __ibm128 long double type. [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__] (num_put::__do_put): Likewise. * include/bits/locale_facets.tcc [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__] (num_get::__do_get, num_put::__do_put): Define. * include/bits/locale_facets_nonio.h [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__] (money_get::__do_get): Declare vtable placeholder for __ibm128 long double type. [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__] (money_put::__do_put): Likewise. * include/bits/locale_facets_nonio.tcc [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__] (money_get::__do_get, money_put::__do_put): Define. * include/ext/numeric_traits.h [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT] (__numeric_traits<__ibm128>, __numeric_traits<__ieee128>): Define. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.am: Add compatibility-ldbl-alt128.cc and compatibility-ldbl-alt128-cxx11.cc sources and recipes for objects. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++11/compatibility-ldbl-alt128-cxx11.cc: New file defining symbols using the old 128-bit long double format, for the cxx11 ABI. * src/c++11/compatibility-ldbl-alt128.cc: Likewise, for the gcc4-compatible ABI. * src/c++11/compatibility-ldbl-facets-aliases.h: New header for long double compat aliases. * src/c++11/cow-locale_init.cc: Add comment. * src/c++11/cxx11-locale-inst.cc: Define C and C_is_char unconditionally. * src/c++11/cxx11-wlocale-inst.cc: Add sanity check. Include locale-inst.cc directly, not via cxx11-locale-inst.cc. * src/c++11/locale-inst-monetary.h: New header for monetary category instantiations. * src/c++11/locale-inst-numeric.h: New header for numeric category instantiations. * src/c++11/locale-inst.cc: Include new headers for monetary, numeric, and long double definitions. * src/c++11/wlocale-inst.cc: Remove long double compat aliases that are defined in new header now. * src/c++17/Makefile.am: Use -mabi=ibmlongdouble for floating_from_chars.cc. * src/c++17/Makefile.in: Regenerate. * src/c++17/floating_from_chars.cc (from_chars_impl): Add if-constexpr branch for __ieee128. (from_chars): Overload for __ieee128. * src/c++20/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * src/c++98/locale_init.cc (num_facets): Adjust calculation. (locale::_Impl::_Impl(size_t)): Call _M_init_extra_ldbl128. * src/c++98/localename.cc (num_facets): Adjust calculation. (locale::_Impl::_Impl(const char*, size_t)): Call _M_init_extra_ldbl128. * src/filesystem/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * testsuite/util/testsuite_abi.cc: Add new symbol versions. Allow new symbols to be added to GLIBCXX_IEEE128_3.4.29 and CXXABI_IEEE128_1.3.13 too. * testsuite/26_numerics/complex/abi_tag.cc: Add u9__ieee128 to regex matching expected symbols.
2020-12-09libstdc++: Fix build failure for target with no way to sleepJonathan Wakely1-1/+4
In previous releases the std::this_thread::sleep_for function was only declared if the target supports multiple threads. I changed that recently in r11-2649-g5bbb1f3000c57fd4d95969b30fa0e35be6d54ffb so that sleep_for could be used single-threaded. But that means that targets using --disable-threads are now required to provide some way to sleep. This breaks the build for (at least) AVR when trying to build a hosted library. This patch adds a new autoconf macro that is defined when no way to sleep is available, and uses that to suppress the sleeping functions in std::this_thread. The #error in src/c++11/thread.cc is retained for the case where there is no sleep function available but multiple threads are supported. This is consistent with previous releases, but that #error could probably be removed without any consequences. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Define NO_SLEEP if none of nanosleep, sleep and Sleep is available. * config.h.in: Regenerate. * configure: Regenerate. * include/std/thread [_GLIBCXX_NO_SLEEP] (__sleep_for): Do not declare. [_GLIBCXX_NO_SLEEP] (sleep_for, sleep_until): Do not define. * src/c++11/thread.cc [_GLIBCXX_NO_SLEEP] (__sleep_for): Do not define.
2020-11-27libstdc++: Partially revert r11-5314Jonathan Wakely2-2/+2
The changes in r11-5314 are broken, because it means we don't use __gthread_once for the first few initializations, but after the program becomes multi-threaded we will repeat the initialization, using __gthread_once once this time. This leads to memory errors. The use of __is_single_threaded() in locale::id::_M_id() is OK, because the side effects are the same either way. libstdc++-v3/ChangeLog: * src/c++98/locale.cc (locale::facet::_S_get_c_locale()): Revert change to use __is_single_threaded. * src/c++98/locale_init.cc (locale::_S_initialize()): Likewise.
2020-11-25libstdc++: Encapsulate __gthread_cond_t as std::__condvarJonathan Wakely1-29/+4
This introduces a new internal utility, std::__condvar, which is a simplified form of std::condition_variable. It has no dependency on <chrono> or std::unique_lock, which allows it to be used in <bits/atomic_wait.h>. This avoids repeating the #ifdef __GTHREAD_COND_INIT preprocessor conditions and associated logic for initializing a __gthread_cond_t correctly. It also encapsulates most of the __gthread_cond_xxx functions as member functions of __condvar. libstdc++-v3/ChangeLog: * include/bits/atomic_timed_wait.h (__cond_wait_until_impl): Do not define when _GLIBCXX_HAVE_LINUX_FUTEX is defined. Use __condvar and mutex instead of __gthread_cond_t and unique_lock<mutex>. (__cond_wait_until): Likewise. Fix test for return value of __cond_wait_until_impl. (__timed_waiters::_M_do_wait_until): Use __condvar instead of __gthread_cond_t. * include/bits/atomic_wait.h: Remove <bits/unique_lock.h> include. Only include <bits/std_mutex.h> if not using futexes. (__platform_wait_max_value): Remove unused variable. (__waiters::lock_t): Use lock_guard instead of unique_lock. (__waiters::_M_cv): Use __condvar instead of __gthread_cond_t. (__waiters::_M_do_wait(__platform_wait_t)): Likewise. (__waiters::_M_notify()): Likewise. Use notify_one() if not asked to notify all. * include/bits/std_mutex.h (__condvar): New type. * include/std/condition_variable (condition_variable::_M_cond) (condition_variable::wait_until): Use __condvar instead of __gthread_cond_t. * src/c++11/condition_variable.cc (condition_variable): Define default constructor and destructor as defaulted. (condition_variable::wait, condition_variable::notify_one) (condition_variable::notify_all): Forward to corresponding member function of __condvar.
2020-11-24libstdc++: Throw instead of segfaulting in std::thread constructor [PR 67791]Jonathan Wakely1-0/+10
This turns a mysterious segfault into an exception with a more useful message. If the exception isn't caught, the user sees this instead of just a segfault: terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Operation not permitted Aborted (core dumped) libstdc++-v3/ChangeLog: PR libstdc++/67791 * src/c++11/thread.cc (thread::_M_start_thread(_State_ptr, void (*)())): Check that gthreads is available before calling __gthread_create.
2020-11-24libstdc++: Use __libc_single_threaded for locale initializationJonathan Wakely2-3/+3
Most initialization of locales and facets happens before main() during startup, when the program is likely to only have one thread. By using the new __gnu_cxx::__is_single_threaded() function instead of checking __gthread_active_p() we can avoid using pthread_once or atomics for the common case. That said, I'm not sure why we don't just use a local static variable instead, as __cxa_guard_acquire() already optimizes for the single-threaded case: static const bool init = (_S_initialize_once(), true); I'll revisit that for GCC 12. libstdc++-v3/ChangeLog: * src/c++98/locale.cc (locale::facet::_S_get_c_locale()) (locale::id::_M_id() const): Use __is_single_threaded. * src/c++98/locale_init.cc (locale::_S_initialize()): Likewise.
2020-11-19libstdc++: Move std::thread to a new headerJonathan Wakely1-0/+1
This makes it possible to use std::thread without including the whole of <thread>. It also makes this_thread::get_id() and this_thread::yield() available even when there is no gthreads support (e.g. when GCC is built with --disable-threads or --enable-threads=single). In order for the std::thread::id return type of this_thread::get_id() to be defined, std:thread itself is defined unconditionally. However the constructor that creates new threads is not defined for single-threaded builds. The thread::join() and thread::detach() member functions are defined inline for single-threaded builds and just throw an exception (because we know the thread cannot be joinable if the constructor that creates joinable threads doesn't exit). The thread::hardware_concurrency() member function is also defined inline and returns 0 (as suggested by the standard when the value "is not computable or well-defined"). The main benefit for most targets is that other headers such as <future> do not need to include the whole of <thread> just to be able to create a std::thread. That avoids including <stop_token> and std::jthread where not required. This is another partial fix for PR 92546. This also means we can use this_thread::get_id() and this_thread::yield() in <stop_token> instead of using the gthread functions directly. This removes some preprocessor conditionals, simplifying the code. libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/Makefile.am: Add new <bits/std_thread.h> header. * include/Makefile.in: Regenerate. * include/std/future: Include new header instead of <thread>. * include/std/stop_token: Include new header instead of <bits/gthr.h>. (stop_token::_S_yield()): Use this_thread::yield(). (_Stop_state_t::_M_requester): Change type to std::thread::id. (_Stop_state_t::_M_request_stop()): Use this_thread::get_id(). (_Stop_state_t::_M_remove_callback(_Stop_cb*)): Likewise. Use __is_single_threaded() to decide whether to synchronize. * include/std/thread (thread, operator==, this_thread::get_id) (this_thread::yield): Move to new header. (operator<=>, operator!=, operator<, operator<=, operator>) (operator>=, hash<thread::id>, operator<<): Define even when gthreads not available. * src/c++11/thread.cc: Include <memory>. * include/bits/std_thread.h: New file. (thread, operator==, this_thread::get_id, this_thread::yield): Define even when gthreads not available. [!_GLIBCXX_HAS_GTHREADS] (thread::join, thread::detach) (thread::hardware_concurrency): Define inline.
2020-11-19libstdc++: Fix overflow checks to use the correct "time_t" [PR 93456]Jonathan Wakely1-6/+8
I recently added overflow checks to src/c++11/futex.cc for PR 93456, but then changed the type of the timespec for PR 93421. This meant the overflow checks were no longer using the right range, because the variable being written to might be smaller than time_t. This introduces new typedef that corresponds to the tv_sec member of the struct being passed to the syscall, and uses that typedef in the range checks. libstdc++-v3/ChangeLog: PR libstdc++/93421 PR libstdc++/93456 * src/c++11/futex.cc (syscall_time_t): New typedef for the type of the syscall_timespec::tv_sec member. (relative_timespec, _M_futex_wait_until) (_M_futex_wait_until_steady): Use syscall_time_t in overflow checks, not time_t.
2020-11-17libstdc++: Revert changes for SYS_clock_gettime64 [PR 93421]Jonathan Wakely2-19/+5
As discussed in the PR, it's incredibly unlikely that a system that needs to use the SYS_clock_gettime syscall (e.g. glibc 2.16 or older) is going to define the SYS_clock_gettime64 macro. Ancient systems that need to use the syscall aren't going to have time64 support. This reverts the recent changes to try and make clock_gettime syscalls be compatible with systems that have been updated for time64 (those changes were wrong anyway as they misspelled the SYS_clock_gettime64 macro). The changes for futex syscalls are retained, because we still use them on modern systems that might be using time64. To ensure that the clock_gettime syscalls are safe, configure will fail if SYS_clock_gettime is needed, and SYS_clock_gettime64 is also defined (but to a distinct value from SYS_clock_gettime), and the tv_sec member of timespec is larger than long. This means we will be unable to build on a hypothetical system where we need the time32 version of SYS_clock_gettime but where userspace is using a time64 struct timespec. In the unlikely event that this failure is triggered on any real systems, we can fix it later. But we probably won't need to. libstdc++-v3/ChangeLog: PR libstdc++/93421 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Fail if struct timespec isn't compatible with SYS_clock_gettime. * configure: Regenerate. * src/c++11/chrono.cc: Revert changes for time64 compatibility. Add static_assert instead. * src/c++11/futex.cc (_M_futex_wait_until_steady): Assume SYS_clock_gettime can use struct timespec.
2020-11-16libstdc++: Fix error shown during Solaris buildJonathan Wakely2-4/+4
Currently this is shown when building libstdc++ on Solaris: -lrt: open: No such file or directory The error comes from the make_sunver.pl script which tries to open each of its arguments. The arguments are passed by this make rule: perl ${glibcxx_srcdir}/scripts/make_exports.pl \ libstdc++-symbols.ver \ $(libstdc___la_OBJECTS:%.lo=.libs/%.o) \ `echo $(libstdc___la_LIBADD) | \ sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ > $@ || (rm -f $@ ; exit 1) The $(libstdc___la_LIBADD) variable includes $(GLIBCXX_LIBS) which contains -lrt on Solaris. This patch adds another sed script to filter -l arguments from the echo command. In order to reliably match ' -l[^ ]* ' the echo arguments are quoted and a space added before and after them. This might be overkill just to remove -lrt from the start of the string, but should be robust in case other -l arguments are added to $(GLIBCXX_LIBS), or in case the $(libstdc___la_LIBADD) libraries are reordered. libstdc++-v3/ChangeLog: * src/Makefile.am (libstdc++-symbols.ver-sun): Remove -lrt from arguments passed to make_sunver.pl script. * src/Makefile.in: Regenerate.
2020-11-13libstdc++: Use custom timespec in system calls [PR 93421]Jonathan Wakely2-8/+32
On 32-bit targets where userspace has switched to 64-bit time_t, we cannot pass struct timespec to SYS_futex or SYS_clock_gettime, because the userspace definition of struct timespec will not match what the kernel expects. We use the existence of the SYS_futex_time64 or SYS_clock_gettime_time64 macros to imply that userspace *might* have switched to the new timespec definition. This is a conservative assumption. It's possible that the new syscall numbers are defined in the libc headers but that timespec hasn't been updated yet (as is the case for glibc currently). But using the alternative struct with two longs is still OK, it's just redundant if userspace timespec still uses a 32-bit time_t. We also check that SYS_futex_time64 != SYS_futex so that we don't try to use a 32-bit tv_sec on modern targets that only support the 64-bit system calls and define the old macro to the same value as the new one. We could possibly check #ifdef __USE_TIME_BITS64 to see whether userspace has actually been updated, but it's not clear if user code is meant to inspect that or if it's only for libc internal use. libstdc++-v3/ChangeLog: PR libstdc++/93421 * src/c++11/chrono.cc [_GLIBCXX_USE_CLOCK_GETTIME_SYSCALL] (syscall_timespec): Define a type suitable for SYS_clock_gettime calls. (system_clock::now(), steady_clock::now()): Use syscall_timespec instead of timespec. * src/c++11/futex.cc (syscall_timespec): Define a type suitable for SYS_futex and SYS_clock_gettime calls. (relative_timespec): Use syscall_timespec instead of timespec. (__atomic_futex_unsigned_base::_M_futex_wait_until): Likewise. (__atomic_futex_unsigned_base::_M_futex_wait_until_steady): Likewise.
2020-11-13libstdc++: Remove redundant overflow check for futex timeout [PR 93456]Jonathan Wakely1-12/+14
The relative_timespec function already checks for the case where the specified timeout is in the past, so the difference can never be negative. That means we dn't need to check if it's more negative than the minimum time_t value. libstdc++-v3/ChangeLog: PR libstdc++/93456 * src/c++11/futex.cc (relative_timespec): Remove redundant check negative values. * testsuite/30_threads/future/members/wait_until_overflow.cc: Moved to... * testsuite/30_threads/future/members/93456.cc: ...here.
2020-11-13libstdc++: Avoid more 32-bit time_t overflows in futex callsJonathan Wakely1-14/+22
This fixes another overflow in code converting a std::chrono::seconds duration to a time_t. This time in the new code using a futex wait with an absolute timeout (so this one doesn't need to be backported to the release branches). A timeout after the epochalypse would overflow the tv_sec field, producing an incorrect value. If that incorrect value happened to be negative, the syscall would return with EINVAL and then the caller would keep retrying, spinning until the timeout was reached. If the value happened to be positive, we would wake up too soon and incorrectly report a timeout libstdc++-v3/ChangeLog: * src/c++11/futex.cc (relative_timespec): Add [[unlikely]] attributes. (__atomic_futex_unsigned_base::_M_futex_wait_until) (__atomic_futex_unsigned_base::_M_futex_wait_until_steady): Check for overflow. * testsuite/30_threads/future/members/wait_until_overflow.cc: New test.
2020-11-13libstdc++: Avoid 32-bit time_t overflows in futex callsJonathan Wakely1-26/+53
The existing code doesn't check whether the chrono::seconds value is out of range of time_t. When using a timeout before the epoch (with a negative value) subtracting the current time (as time_t) and then assigning it to a time_t can overflow to a large positive value. This means that we end up waiting several years even though the specific timeout was in the distant past. We do have a check for negative timeouts, but that happens after the conversion to time_t so happens after the overflow. The conversion to a relative timeout is done in two places, so this factors it into a new function and adds the overflow checks there. libstdc++-v3/ChangeLog: * src/c++11/futex.cc (relative_timespec): New function to create relative time from two absolute times. (__atomic_futex_unsigned_base::_M_futex_wait_until) (__atomic_futex_unsigned_base::_M_futex_wait_until_steady): Use relative_timespec.
2020-11-12libstdc++: Optimise std::future::wait_for and fix futex pollingJonathan Wakely1-0/+9
To poll a std::future to see if it's ready you have to call one of the timed waiting functions. The most obvious way is wait_for(0s) but this was previously very inefficient because it would turn the relative timeout to an absolute one by calling system_clock::now(). When the relative timeout is zero (or less) we're obviously going to get a time that has already passed, but the overhead of obtaining the current time can be dozens of microseconds. The alternative is to call wait_until with an absolute timeout that is in the past. If you know the clock's epoch is in the past you can use a default constructed time_point. Alternatively, using some_clock::time_point::min() gives the earliest time point supported by the clock, which should be safe to assume is in the past. However, using a futex wait with an absolute timeout before the UNIX epoch fails and sets errno=EINVAL. The new code using futex waits with absolute timeouts was not checking for this case, which could result in hangs (or killing the process if the libray is built with assertions enabled). This patch checks for times before the epoch before attempting to wait on a futex with an absolute timeout, which fixes the hangs or crashes. It also makes it very fast to poll using an absolute timeout before the epoch (because we skip the futex syscall). It also makes future::wait_for avoid waiting at all when the relative timeout is zero or less, to avoid the unnecessary overhead of getting the current time. This makes polling with wait_for(0s) take only a few cycles instead of dozens of milliseconds. libstdc++-v3/ChangeLog: * include/std/future (future::wait_for): Do not wait for durations less than or equal to zero. * src/c++11/futex.cc (_M_futex_wait_until) (_M_futex_wait_until_steady): Do not wait for timeouts before the epoch. * testsuite/30_threads/future/members/poll.cc: New test.
2020-11-10libstdc++: Add remaining C++20 additions to <sstream> [P0408R7]Jonathan Wakely1-0/+48
This adds the new overloads of basic_stringbuf::str, and the corresponding overloads to basic_istringstream, basic_ostringstream and basic_stringstream. libstdc++-v3/ChangeLog: * config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Tighten patterns. (GLIBCXX_3.4.29): Export new symbols. * include/bits/alloc_traits.h (__allocator_like): New concept. * include/std/sstream (basic_stringbuf::swap): Add exception specification. (basic_stringbuf::str() const): Add ref-qualifier. Use new _M_high_mark function. (basic_stringbuf::str(const SAlloc&) const): Define new function. (basic_stringbuf::str() &&): Likewise. (basic_stringbuf::str(const basic_string<C,T,SAlloc>&)): Likewise. (basic_stringbuf::str(basic_string<C,T,Alloc>&&)): Likewise. (basic_stringbuf::view() const): Use _M_high_mark. (basic_istringstream::str, basic_ostringstream::str) (basic_stringstream::str): Define new overloads. * src/c++20/sstream-inst.cc (basic_stringbuf::str) (basic_istringstream::str, basic_ostringstream::str) (basic_stringstream::str): Explicit instantiation definitions for new overloads. * testsuite/27_io/basic_istringstream/view/char/1.cc: Add more checks. * testsuite/27_io/basic_istringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_stringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_stringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_istringstream/str/char/2.cc: New test. * testsuite/27_io/basic_istringstream/str/wchar_t/2.cc: New test. * testsuite/27_io/basic_ostringstream/str/char/3.cc: New test. * testsuite/27_io/basic_ostringstream/str/wchar_t/3.cc: New test. * testsuite/27_io/basic_stringbuf/str/char/4.cc: New test. * testsuite/27_io/basic_stringbuf/str/wchar_t/4.cc: New test. * testsuite/27_io/basic_stringstream/str/char/5.cc: New test. * testsuite/27_io/basic_stringstream/str/wchar_t/5.cc.cc: New test.
2020-11-05libstdc++: Use non-throwing increment in recursive_directory_iterator [PR 97731]Jonathan Wakely1-7/+11
As described in the PR, the recursive_directory_iterator constructor calls advance(ec), but ec is a pointer so it calls _Dir::advance(bool). The intention was to either call advance() or advance(*ec) depending whether the pointer is null or not. This fixes the bug and renames the parameter to ecptr to make similar mistakes less likely in future. libstdc++-v3/ChangeLog: PR libstdc++/97731 * src/filesystem/dir.cc (recursive_directory_iterator): Call the right overload of _Dir::advance. * testsuite/experimental/filesystem/iterators/97731.cc: New test.
2020-11-05libstdc++: Export basic_stringbuf constructor [PR 97729]Jonathan Wakely1-0/+6
libstdc++-v3/ChangeLog: PR libstdc++/97729 * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add exports. * src/c++20/sstream-inst.cc (basic_stringbuf): Instantiate private constructor taking __xfer_bufptrs.
2020-11-05libstdc++: Fix new <sstream> constructorsJonathan Wakely1-4/+2
- Add a missing 'explicit' to a basic_stringbuf constructor. - Set up the get/put area pointers in the constructor from strings using different allocator types. - Remove public basic_stringbuf::__sv_type alias. - Do not construct temporary basic_string objects with a default-constructed allocator. Also, change which basic_string constructor is used, as a minor compile-time optimization. Constructing from a basic_string_view requires more work from the compiler, so just use a pointer and length. libstdc++-v3/ChangeLog: * include/std/sstream (basic_stringbuf(const allocator_type&): Add explicit. (basic_stringbuf(const basic_string<C,T,SA>&, openmode, const A&)): Call _M_stringbuf_init. Construct _M_string from pointer and length to avoid constraint checks for string view. (basic_stringbuf::view()): Make __sv_type alias local to the function. (basic_istringstream(const basic_string<C,T,SA>&, openmode, const A&)): Pass string to _M_streambuf instead of constructing a temporary with the wrong allocator. (basic_ostringstream(const basic_string<C,T,SA>&, openmode, const A&)): Likewise. (basic_stringstream(const basic_string<C,T,SA>&, openmode, const A&)): Likewise. * src/c++20/sstream-inst.cc: Use string_view and wstring_view typedefs in explicit instantiations. * testsuite/27_io/basic_istringstream/cons/char/1.cc: Add more tests for constructors. * testsuite/27_io/basic_ostringstream/cons/char/1.cc: Likewise. * testsuite/27_io/basic_stringbuf/cons/char/1.cc: Likewise. * testsuite/27_io/basic_stringbuf/cons/char/2.cc: Likewise. * testsuite/27_io/basic_stringbuf/cons/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_stringbuf/cons/wchar_t/2.cc: Likewise. * testsuite/27_io/basic_stringstream/cons/char/1.cc: Likewise.
2020-11-03libstdc++: Refactor std::call_once internalsJonathan Wakely1-29/+39
This separates the definition of std::__call_proxy into two funcions, one for TLS and one for non-TLS, to make them easier to read. It also replaces the __get_once_functor_lock_ptr() internal helper with a new set_lock_ptr(unique_lock<mutex>*) function so that __once_proxy doesn't need to call it twice. libstdc++-v3/ChangeLog: * src/c++11/mutex.cc [_GLIBCXX_HAVE_TLS] (__once_proxy): Define separately for TLS targets. [!_GLIBCXX_HAVE_TLS] (__get_once_functor_lock_ptr): Replace with ... (set_lock_ptr): ... this. Set new value and return previous value. [!_GLIBCXX_HAVE_TLS] (__set_once_functor_lock_ptr): Adjust to use set_lock_ptr. [!_GLIBCXX_HAVE_TLS] (__once_proxy): Likewise.
2020-11-03libstdc++: Rewrite std::call_once to use futexes [PR 66146]Jonathan Wakely1-0/+59
The current implementation of std::call_once uses pthread_once, which only meets the C++ requirements when compiled with support for exceptions. For most glibc targets and all non-glibc targets, pthread_once does not work correctly if the init_routine exits via an exception. The pthread_once_t object is left in the "active" state, and any later attempts to run another init_routine will block forever. This change makes std::call_once work correctly for Linux targets, by replacing the use of pthread_once with a futex, based on the code from __cxa_guard_acquire. For both glibc and musl, the Linux implementation of pthread_once is already based on futexes, and pthread_once_t is just a typedef for int, so this change does not alter the layout of std::once_flag. By choosing the values for the int appropriately, the new code is even ABI compatible. Code that calls the old implementation of std::call_once will use pthread_once to manipulate the int, while new code will use the new std::once_flag members to manipulate it, but they should interoperate correctly. In both cases, the int is initially zero, has the lowest bit set when there is an active execution, and equals 2 after a successful returning execution. The difference with the new code is that exceptional exceptions are correctly detected and the int is reset to zero. The __cxa_guard_acquire code (and musl's pthread_once) use an additional state to say there are other threads waiting. This allows the futex wake syscall to be skipped if there is no contention. Glibc doesn't use a waiter bit, so we have to unconditionally issue the wake in order to be compatible with code calling the old std::call_once that uses Glibc's pthread_once. If we know that we're using musl (and musl's pthread_once doesn't change) it would be possible to set a waiting state and check for it in std::once_flag::_M_finish(bool), but this patch doesn't do that. This doesn't fix the bug for non-linux targets. A similar approach could be used for targets where we know the definition of pthread_once_t is a mutex and an integer. We could make once_flag._M_activate() use pthread_mutex_lock on the mutex member within the pthread_once_t, and then only set the integer if the execution finishes, and then unlock the mutex. That would require careful study of each target's pthread_once implementation and that work is left for a later date. This also fixes PR 55394 because pthread_once is no longer needed, and PR 84323 because the fast path is now just an atomic load. As a consequence of the new implementation that doesn't use pthread_once, we can also make std::call_once work for targets with no gthreads support. The code for the single-threaded implementation follows the same methods as on Linux, but with no need for atomics or futexes. libstdc++-v3/ChangeLog: PR libstdc++/55394 PR libstdc++/66146 PR libstdc++/84323 * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols. * include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define even when gthreads is not supported. (once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type from __gthread_once_t to int. (once_flag::_M_passive(), once_flag::_M_activate()) (once_flag::_M_finish(bool), once_flag::_Active_execution): Define new members for futex and non-threaded implementation. [_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New RAII helper type. (call_once): Use new members of once_flag. * src/c++11/mutex.cc (std::once_flag::_M_activate): Define. (std::once_flag::_M_finish): Define. * testsuite/30_threads/call_once/39909.cc: Do not require gthreads. * testsuite/30_threads/call_once/49668.cc: Likewise. * testsuite/30_threads/call_once/60497.cc: Likewise. * testsuite/30_threads/call_once/call_once1.cc: Likewise. * testsuite/30_threads/call_once/dr2442.cc: Likewise. * testsuite/30_threads/call_once/once_flag.cc: Add test for constexpr constructor. * testsuite/30_threads/call_once/66146.cc: New test. * testsuite/30_threads/call_once/constexpr.cc: Removed. * testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.
2020-11-03libstdc++: use lt_host_flags for libstdc++.laJonathan Yong2-2/+2
For platforms like Mingw and Cygwin, cygwin refuses to generate the shared library without using -no-undefined. Attached patch makes sure the right flags are used, since libtool is already used to link libstdc++. libstdc++-v3/ChangeLog: * src/Makefile.am (libstdc___la_LINK): Add lt_host_flags. * src/Makefile.in: Regenerate.
2020-10-31libstdc++: Fix gnu-version-namespace buidFrançois Dumont2-4/+50
Co-authored-by: Jonathan Wakely <jwakely@redhat.com> libstdc++-v3/ChangeLog * src/c++17/floating_from_chars.cc (_GLIBCXX_USE_CX11_ABI): Add define. (buffering_string): New. [!_GLIBCXX_USE_CXX11_ABI](reserve_string): New. (from_chars): Adapt. * src/c++20/sstream-inst.cc: Limit instantiations to _GLIBCXX_USE_CXX11_ABI.
2020-10-31libstdc++: Use double for unordered container load factors [PR 96958]Jonathan Wakely1-6/+6
My previous commit for this PR changed the types from long double to double, but didn't change the uses of __builtin_ceill and __builtin_floorl. It also failed to change the non-inline functions in src/c++11/hashtable_c++0x.cc. This should fix it properly now. libstdc++-v3/ChangeLog: PR libstdc++/96958 * include/bits/hashtable_policy.h (_Prime_rehash_policy) (_Power2_rehash_policy): Use ceil and floor instead of ceill and floorl. * src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy): Likewise. Use double instead of long double.
2020-10-28libstdc++: Implement C++20 features for <sstream>Thomas Rodgers5-9/+965
New ctors and ::view() accessor for - * basic_stingbuf * basic_istringstream * basic_ostringstream * basic_stringstreamm New ::get_allocator() accessor for basic_stringbuf. libstdc++-v3/ChangeLog: * acinclude.m4 (glibcxx_SUBDIRS): Add src/c++20. * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): New symbols. * configure: Regenerate. * include/std/sstream: (basic_stringbuf::basic_stringbuf(allocator const&)): New constructor. (basic_stringbuf::basic_stringbuf(openmode, allocator const&)): Likewise. (basic_stringbuf::basic_stringbuf(basic_string&&, openmode)): Likewise. (basic_stringbuf::basic_stringbuf(basic_stringbuf&&, allocator const&)): Likewise. (basic_stringbuf::get_allocator()): New method. (basic_stringbuf::view()): Likewise. (basic_istringstream::basic_istringstream(basic_string&&, openmode)): New constructor. (basic_istringstream::basic_istringstream(openmode, allocator const&)): Likewise (basic_istringstream::view()): New method. (basic_ostringstream::basic_ostringstream(basic_string&&, openmode)): New constructor. (basic_ostringstream::basic_ostringstream(openmode, allocator const&)): Likewise (basic_ostringstream::view()): New method. (basic_stringstream::basic_stringstream(basic_string&&, openmode)): New constructor. (basic_stringstream::basic_stringstream(openmode, allocator const&)): Likewise (basic_stringstream::view()): New method. * src/Makefile.in: Add c++20 directory. * src/Makefile.am: Regenerate. * src/c++20/Makefile.am: Add makefile for new sub-directory. * src/c++20/Makefile.in: Generate. * src/c++20/sstream-inst.cc: New file defining explicit instantiations for basic_stringbuf, basic_istringstream, basic_ostringstream, and basic_stringstream member functions added in C++20. * testsuite/27_io/basic_stringbuf/cons/char/2.cc: New test. * testsuite/27_io/basic_stringbuf/cons/wchar_t/2.cc: Likewise. * testsuite/27_io/basic_stringbuf/view/char/1.cc: Likewise. * testsuite/27_io/basic_stringbuf/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_istringstream/cons/char/1.cc: Likewise. * testsuite/27_io/basic_istringstream/cons/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_istringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_istringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/cons/char/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/cons/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_stringstream/cons/char/1.cc: Likewise. * testsuite/27_io/basic_stringstream/cons/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_stringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_stringstream/view/wchar_t/1.cc: Likewise.
2020-10-27libstdc++: Fix directory_iterator exception specificationJonathan Wakely1-5/+1
libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc (fs::directory_iterator::operator*): Add noexcept. Do not throw on precondition violation.