libstdc++-v3/ChangeLog:
PR libstdc++/98725
* testsuite/20_util/unique_ptr/io/lwg2948.cc: Do not try to
write to a wide character stream if wide character support is
disabled in the library.
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.
-fcf-protection is automatically enabled in libstdc++ on Linux/x86.
Starting from
commit 77d372abec
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Jan 14 05:56:46 2021 -0800
x86: Error on -fcf-protection with incompatible target
GCC issues an error on -fcf-protection with incompatible target:
... -fcf-protection ... libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc -m32 -O2 -g0 -fno-exceptions -fno-asynchronous-unwind-tables -march=i486 ...
cc1plus: error: '-fcf-protection' is not compatible with this target
FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess errors)
Add -fcf-protection=none to -march=i486 to compile explicit-hle.cc.
* testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc:
Add -fcf-protection=none to -march=i486.
We get occasional failures of 30_threads/future/members/poll.cc
on some platforms whose high resolution clock doesn't have such a high
resolution; wait_for_0 ends up as 0, and then some asserts fail as
intervals measured as longer than zero are tested for less than
several times zero.
This patch adds some calibration in the iteration count to set a
measurable base time interval with some additional margin.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/future/members/poll.cc: Calibrate
iteration count.
Fix ordering problem on Windows targets where filesystem_error was used
before being defined.
libstdc++-v3/ChangeLog:
PR libstdc++/98471
* include/bits/fs_path.h (__throw_conversion_error): New
function to throw or abort on character conversion errors.
(__wstr_from_utf8): Move definition after filesystem_error has
been defined. Use __throw_conversion_error.
(path::_S_convert<_EcharT>): Use __throw_conversion_error.
(path::_S_str_convert<_CharT, _Traits, _Allocator>): Likewise.
(path::u8string): Likewise.
The patch adding these files was approved in 2020 but it wasn't
committed until 2021, so the copyright years were not updated along with
the years in all the existing files.
libstdc++-v3/ChangeLog:
* include/std/barrier: Update copyright years. Fix whitespace.
* include/std/version: Fix whitespace.
* testsuite/30_threads/barrier/1.cc: Update copyright years.
* testsuite/30_threads/barrier/2.cc: Likewise.
* testsuite/30_threads/barrier/arrive.cc: Likewise.
* testsuite/30_threads/barrier/arrive_and_drop.cc: Likewise.
* testsuite/30_threads/barrier/arrive_and_wait.cc: Likewise.
* testsuite/30_threads/barrier/completion.cc: Likewise.
This header was removed recently, so Doxygen shouldn't try to process
it.
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (INPUT): Remove include/debug/array.
The testcase was failing to compile on some targets due to its use of
the non-standard functions nextupl and nextdownl. This patch makes the
testcase instead use the C99 function nexttowardl in an equivalent way.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Use nexttowardl
instead of the non-standard nextupl and nextdownl.
libstdc++-v3:
2020-12-26 Gerald Pfeifer <gerald@pfeifer.com>
* doc/xml/manual/abi.xml: Update link to Intel's compatibility
with GNU compilers document.
* doc/html/manual/abi.html: Regenerate.
Undefine various macros unexpectedly defined by VxWorks headers.
for libstdc++-v3/ChangeLog
* testsuite/17_intro/names.cc: Account for VxWorks headers.
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.
The testcases are imported almost verbatim, with the only change being
to the -double_nan and -float_nan testcases. We expect these values to
be formatted as "-nan" instead of "-nan(ind)".
libstdc++-v3/ChangeLog:
* testsuite/20_util/to_chars/double.cc: New test, consisting of
testcases imported from the MSVC STL testsuite.
* testsuite/20_util/to_chars/float.cc: 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.
