Since Ryu has the alias uint128_t for this same purpose, it seems best
for us to use this name as well, so as to minimize the amount of local
modifications we'd need to make to our copy of Ryu. (In a subsequent
patch, we're going to remove Ryu's aliases so that it uses this one
defined in floating_to_chars.cc.)
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (uint128_t): New conditionally
defined alias of unsigned __int128.
(floating_type_traits_binary128::mantissa_t): Use uint128_t
instead of unsigned __int128.
(floating_type_traits<long double>::mantissa_t)
[LONG_DOUBLE_KIND == LDK_IBM128]: Likewise.
(get_ieee_repr): Likewise. Make casts from uint_t to mantissa_t
and uint32_t explicit. Simplify the extraction of mantissa,
exponent and sign bit.
Contrary to what POSIX says, some directory operations on MacOS can fail
with EPERM instead of EACCES, so we need to handle both.
libstdc++-v3/ChangeLog:
PR libstdc++/99537
* src/c++17/fs_dir.cc (recursive_directory_iterator): Use new
helper function to check for permission denied errors.
* src/filesystem/dir.cc (recursive_directory_iterator):
Likewise.
* src/filesystem/dir-common.h (is_permission_denied_error): New
helper function.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 '.'.
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.
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.
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.
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.
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.
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.
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.
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:🆔:_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.
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.
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:🧵 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.
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:🆔:_M_id() const): Use __is_single_threaded.
* src/c++98/locale_init.cc (locale::_S_initialize()):
Likewise.
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:🧵: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:🧵: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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
