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 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.
This should have been done before the GCC 10.1 release.
libstdc++-v3/ChangeLog:
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt:
Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
Update.
The change in r11-4748-50b840ac5e1d6534e345c3fee9a97ae45ced6bc7 causes
a build error on Solaris, due to the new explicit instantiation matching
patterns for two different symbol versions.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Tighten up patterns
for basic_stringbuf that refer to __xfer_bufptrs.
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.
This should fix a bootstrap error on Solaris, due to some of the new
symbols matching old patterns as well as new ones.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Tighten patterns
for old <sstream> symbols some more.
This inlines most members of std::exception_ptr so that all operations
on a null exception_ptr can be optimized away. This benefits code like
std::future and coroutines where an exception_ptr object is present to
cope with exceptional cases, but is usually not used and remains null.
Since those functions were previously non-inline we have to continue to
export them from the library, for objects that were compiled against the
old headers and expect to find definitions in the library.
In order to inline the copy constructor and destructor we need to export
the _M_addref() and _M_release() members that increment/decrement the
reference count when copying/destroying a non-null exception_ptr. The
copy ctor and dtor check for null and don't call _M_addref and
_M_release unless they need to. The checks for null pointers in
_M_addref and _M_release are still needed because old code might call
them without checking for null first. But we can use __builtin_expect to
predict that they are usually called for the non-null case.
libstdc++-v3/ChangeLog:
PR libstdc++/90295
* config/abi/pre/gnu.ver (CXXABI_1.3.13): New symbol version.
(exception_ptr::_M_addref(), exception_ptr::_M_release()):
Export symbols.
* libsupc++/eh_ptr.cc (exception_ptr::exception_ptr()):
Remove out-of-line definition.
(exception_ptr::exception_ptr(const exception_ptr&)):
Likewise.
(exception_ptr::~exception_ptr()): Likewise.
(exception_ptr::operator=(const exception_ptr&)):
Likewise.
(exception_ptr::swap(exception_ptr&)): Likewise.
(exception_ptr::_M_addref()): Add branch prediction.
* libsupc++/exception_ptr.h (exception_ptr::operator bool):
Add noexcept.
[!_GLIBCXX_EH_PTR_COMPAT] (operator==, operator!=): Define
inline as hidden friends. Remove declarations at namespace
scope.
(exception_ptr::exception_ptr()): Define inline.
(exception_ptr::exception_ptr(const exception_ptr&)):
Likewise.
(exception_ptr::~exception_ptr()): Likewise.
(exception_ptr::operator=(const exception_ptr&)):
Likewise.
(exception_ptr::swap(exception_ptr&)): Likewise.
* testsuite/util/testsuite_abi.cc: Add CXXABI_1.3.13.
* testsuite/18_support/exception_ptr/90295.cc: New test.
std::allocator and std::pmr::polymorphic_allocator should throw
std::bad_array_new_length from their allocate member functions if the
number of bytes required cannot be represented in std::size_t.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver: Add new symbol.
* include/bits/functexcept.h (__throw_bad_array_new_length):
Declare new function.
* include/ext/malloc_allocator.h (malloc_allocator::allocate):
Throw bad_array_new_length for impossible sizes (LWG 3190).
* include/ext/new_allocator.h (new_allocator::allocate):
Likewise.
* include/std/memory_resource (polymorphic_allocator::allocate)
(polymorphic_allocator::allocate_object): Use new function,
__throw_bad_array_new_length.
* src/c++11/functexcept.cc (__throw_bad_array_new_length):
Define.
* testsuite/20_util/allocator/lwg3190.cc: New test.
The user-visible effect of this change is for std::future::wait_until to
use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock
type. This makes it immune to any changes made to the system clock
CLOCK_REALTIME.
Add an overload of __atomic_futex_unsigned::_M_load_and_text_until_impl
that accepts a std::chrono::steady_clock, and correctly passes this
through to __atomic_futex_unsigned_base::_M_futex_wait_until_steady
which uses CLOCK_MONOTONIC for the timeout within the futex system call.
These functions are mostly just copies of the std::chrono::system_clock
versions with small tweaks.
Prior to this commit, a std::chrono::steady timeout would be converted
via std::chrono::system_clock which risks reducing or increasing the
timeout if someone changes CLOCK_REALTIME whilst the wait is happening.
(The commit immediately prior to this one increases the window of
opportunity for that from a short period during the calculation of a
relative timeout, to the entire duration of the wait.)
FUTEX_WAIT_BITSET was added in kernel v2.6.25. If futex reports ENOSYS
to indicate that this operation is not supported then the code falls
back to using clock_gettime(2) to calculate a relative time to wait for.
I believe that I've added this functionality in a way that it doesn't
break ABI compatibility, but that has made it more verbose and less type
safe. I believe that it would be better to maintain the timeout as an
instance of the correct clock type all the way down to a single
_M_futex_wait_until function with an overload for each clock. The
current scheme of separating out the seconds and nanoseconds early risks
accidentally calling the wait function for the wrong clock.
Unfortunately, doing this would break code that compiled against the old
header.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver: Update for addition of
__atomic_futex_unsigned_base::_M_futex_wait_until_steady.
* include/bits/atomic_futex.h (__atomic_futex_unsigned_base):
Add comments to clarify that _M_futex_wait_until and
_M_load_and_test_until use CLOCK_REALTIME.
(__atomic_futex_unsigned_base::_M_futex_wait_until_steady)
(__atomic_futex_unsigned_base::_M_load_and_text_until_steady):
New member functions that use CLOCK_MONOTONIC.
(__atomic_futex_unsigned_base::_M_load_and_test_until_impl)
(__atomic_futex_unsigned_base::_M_load_when_equal_until): Add
overloads that accept a steady_clock time_point and use the
new member functions.
* src/c++11/futex.cc: Include headers required for
clock_gettime.
(futex_clock_monotonic_flag): New constant to tell futex to
use CLOCK_MONOTONIC to match existing futex_clock_realtime_flag.
(futex_clock_monotonic_unavailable): New global to store the
result of trying to use CLOCK_MONOTONIC.
(__atomic_futex_unsigned_base::_M_futex_wait_until_steady): Add
new variant of _M_futex_wait_until that uses CLOCK_MONOTONIC to
support waiting using steady_clock.
When making the patterns less greedy I forgot to use [jmy] for unsigned
integer parameters.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver: Fix wildcards for wstring symbols.
Remove ability for reserve(n) to reduce a string's capacity. Add a new
reserve() overload that makes a shrink-to-fit request, and make
shrink_to_fit() use that.
libstdc++-v3/ChangeLog:
2020-07-30 Andrew Luo <andrewluotechnologies@outlook.com>
Jonathan Wakely <jwakely@redhat.com>
* config/abi/pre/gnu.ver (GLIBCXX_3.4): Use less greedy
patterns for basic_string members.
(GLIBCXX_3.4.29): Export new basic_string::reserve symbols.
* doc/xml/manual/status_cxx2020.xml: Update P0966 status.
* include/bits/basic_string.h (shrink_to_fit()): Call reserve().
(reserve(size_type)): Remove default argument.
(reserve()): Declare new overload.
[!_GLIBCXX_USE_CXX11_ABI] (shrink_to_fit, reserve): Likewise.
* include/bits/basic_string.tcc (reserve(size_type)): Remove
support for shrinking capacity.
(reserve()): Perform shrink-to-fit operation.
[!_GLIBCXX_USE_CXX11_ABI] (reserve): Likewise.
* testsuite/21_strings/basic_string/capacity/1.cc: Adjust to
reflect new behavior.
* testsuite/21_strings/basic_string/capacity/char/1.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/char/18654.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/char/2.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/1.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/18654.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/2.cc:
Likewise.
P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads
that have high risk of buffer overflows. They were replaced by
equivalents that only accept a reference to an array, and so can
guarantee not to write past the end of the array.
In order to support both the old and new functionality, this patch
introduces a new overloaded __istream_extract function which takes a
maximum length. The new operator>> overloads use the array size as the
maximum length. The old overloads now use __builtin_object_size to
determine the available buffer size if available (which requires -O2) or
use numeric_limits<streamsize>::max()/sizeof(char_type) otherwise. This
is a change in behaviour, as the old overloads previously always used
numeric_limits<streamsize>::max(), without considering sizeof(char_type)
and without attempting to prevent overflows.
Because they now do little more than call __istream_extract, the old
operator>> overloads are very small inline functions. This means there
is no advantage to explicitly instantiating them in the library (in fact
that would prevent the __builtin_object_size checks from ever working).
As a result, the explicit instantiation declarations can be removed from
the header. The explicit instantiation definitions are still needed, for
backwards compatibility with existing code that expects to link to the
definitions in the library.
While working on this change I noticed that src/c++11/istream-inst.cc
has the following explicit instantiation definition:
template istream& operator>>(istream&, char*);
This had no effect (and so should not have been present in that file),
because there was an explicit specialization declared in <istream> and
defined in src/++98/istream.cc. However, this change removes the
explicit specialization, and now the explicit instantiation definition
is necessary to ensure the symbol gets defined in the library.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Export new symbols.
* include/bits/istream.tcc (__istream_extract): New function
template implementing both of operator>>(istream&, char*) and
operator>>(istream&, char(&)[N]). Add explicit instantiation
declaration for it. Remove explicit instantiation declarations
for old function templates.
* include/std/istream (__istream_extract): Declare.
(operator>>(basic_istream<C,T>&, C*)): Define inline and simply
call __istream_extract.
(operator>>(basic_istream<char,T>&, signed char*)): Likewise.
(operator>>(basic_istream<char,T>&, unsigned char*)): Likewise.
(operator>>(basic_istream<C,T>&, C(7)[N])): Define for LWG 2499.
(operator>>(basic_istream<char,T>&, signed char(&)[N])):
Likewise.
(operator>>(basic_istream<char,T>&, unsigned char(&)[N])):
Likewise.
* include/std/streambuf (basic_streambuf): Declare char overload
of __istream_extract as a friend.
* src/c++11/istream-inst.cc: Add explicit instantiation
definition for wchar_t overload of __istream_extract. Remove
explicit instantiation definitions of old operator>> overloads
for versioned-namespace build.
* src/c++98/istream.cc (operator>>(istream&, char*)): Replace
with __istream_extract(istream&, char*, streamsize).
* testsuite/27_io/basic_istream/extractors_character/char/3.cc:
Do not use variable-length array.
* testsuite/27_io/basic_istream/extractors_character/char/4.cc:
Do not run test for C++20.
* testsuite/27_io/basic_istream/extractors_character/char/9555-ic.cc:
Do not test writing to pointers for C++20.
* testsuite/27_io/basic_istream/extractors_character/char/9826.cc:
Use array instead of pointer.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/3.cc:
Do not use variable-length array.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc:
Do not run test for C++20.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/9555-ic.cc:
Do not test writing to pointers for C++20.
* testsuite/27_io/basic_istream/extractors_character/char/lwg2499.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/char/lwg2499_neg.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/char/overflow.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499_neg.cc:
New test.
This adds the missing std::from_chars overloads for floating-point
types, as required for C++17 conformance.
The implementation is a hack and not intended to be used in the long
term. Rather than parsing the string directly, this determines the
initial portion of the string that matches the pattern determined by the
chars_format parameter, then creates a NTBS to be parsed by strtod (or
strtold or strtof).
Because creating a NTBS requires allocating memory, but std::from_chars
is noexcept, we need to be careful to minimise allocation. Even after
being careful, allocation failure is still possible, and so a
non-conforming std::no_more_memory error code might be returned.
Because strtod et al depend on the current locale, but std::from_chars
does not, we change the current thread's locale to "C" using newlocale
and uselocale before calling strtod, and restore it afterwards.
Because strtod doesn't have the equivalent of a std::chars_format
parameter, it has to examine the input to determine the format in use,
even though the std::from_chars code has already parsed it once (or
twice for large input strings!)
By replacing the use of strtod we could avoid allocation, avoid changing
locale, and use optimised code paths specific to each std::chars_format
case. We would also get more portable behaviour, rather than depending
on the presence of uselocale, and on any bugs or quirks of the target
libc's strtod. Replacing strtod is a project for a later date.
libstdc++-v3/ChangeLog:
* acinclude.m4 (libtool_VERSION): Bump version.
* config.h.in: Regenerate.
* config/abi/pre/gnu.ver: Add GLIBCXX_3.4.29 version and new
exports.
* config/os/gnu-linux/ldbl-extra.ver: Add _GLIBCXX_LDBL_3.4.29
version and new export.
* configure: Regenerate.
* configure.ac: Check for <xlocale.h> and uselocale.
* crossconfig.m4: Add macro or checks for uselocale.
* include/std/charconv (from_chars): Declare overloads for
float, double, and long double.
* src/c++17/Makefile.am: Add new file.
* src/c++17/Makefile.in: Regenerate.
* src/c++17/floating_from_chars.cc: New file.
(from_chars): Define for float, double, and long double.
* testsuite/20_util/from_chars/1_c++20_neg.cc: Prune extra
diagnostics caused by new overloads.
* testsuite/20_util/from_chars/1_neg.cc: Likewise.
* testsuite/20_util/from_chars/2.cc: Check leading '+'.
* testsuite/20_util/from_chars/4.cc: New test.
* testsuite/20_util/from_chars/5.cc: New test.
* testsuite/util/testsuite_abi.cc: Add new symbol versions.
I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet. This patch corrects this for Solaris/SPARC
and x86.
Created on master with make new-abi-baseline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, bootstrapped on gcc-10 branch without regressions.
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> I just remembered that the libstdc++ ABI baselines haven't been updated
> for the GCC 10 release yet. This patch corrects this for Solaris/SPARC
> and x86.
Oops, here are the updates from Fedora packages built during the weekend.
2020-05-06 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
This prevents the vtables and RTTI from being emitted in every object
file that uses memory_resource and monotonic_buffer_resource.
Objects compiled by GCC 9.1 or 9.2 will contain inline definitions of
the destructors, vtable and RTTI, but this is harmless. The inline
definitions have identical effects to the ones that are now defined in
libstdc++.so so it doesn't matter if the inline ones are used instead of
calling the symbols exported from the runtime library.
PR libstdc++/93208
* config/abi/pre/gnu.ver: Add new exports.
* include/std/memory_resource (memory_resource::~memory_resource()):
Do not define inline.
(monotonic_buffer_resource::~monotonic_buffer_resource()): Likewise.
* src/c++17/memory_resource.cc (memory_resource::~memory_resource()):
Define.
(monotonic_buffer_resource::~monotonic_buffer_resource()): Define.
* testsuite/20_util/monotonic_buffer_resource/93208.cc: New test.
From-SVN: r280044
The only symbols matched by std::e[a-q]* and std::e[s-z]* that are
supposed to be in the GLIBCXX_3.4 version are std::exception::* and
std::endl and std::ends. The latter two already have explicit patterns
matching them, so we just need to match std::exception::*.
This change ensures that any new symbols with a return type of
std::enable_if<...> are not added to the GLIBCXX_3.4 version.
* config/abi/pre/gnu.ver: Tighten up greedy wildcards.
From-SVN: r276468
The copy assignment operator for recursive_directory_iterator was not
exported despite being needed. The __shared_ptr default constructors are
not needed when compiling with GCC but Clang requires them for -O1.
PR libstdc++/91067
* acinclude.m4 (libtool_VERSION): Bump to 6:27:0.
* configure: Regenerate.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.27): Add new version. Export
missing symbols.
* testsuite/27_io/filesystem/iterators/91067.cc: New test.
* testsuite/util/testsuite_abi.cc: Add new symbol version.
From-SVN: r273023
Jakub noted in https://gcc.gnu.org/ml/libstdc++/2019-04/msg00140.html
that an unwanted std::wstring::_M_replace_dispatch symbol has started to
be exported from the Fedora shared library. This symbol is triggered by
the instantiation of std::wstring::assign(const char*, const char*) from
std::__str_codecvt_in which is called from path::_S_convert_loc. The
branch that triggers that instantiation can't actually happen in that
case, because codecvt facets will only return noconv when the input and
output types are the same. Guarding the assign call with an if-constexpr
check that the types are the same avoids instantiating template
specializations that will never actually be needed.
* config/abi/pre/gnu.ver (GLIBCXX_3.4): Replace wildcard that matches
wstring::_M_replace_dispatch with more specific patterns.
* include/bits/fs_path.h (path::_S_convert_loc<_InputIterator>):
Create const std::string to avoid redundant call to _S_convert_loc
with non-const pointers.
* include/bits/locale_conv.h (__do_str_codecvt): Use if-constexpr to
avoid unnecessary basic_string::assign instantiations.
From-SVN: r270602
