This testcase is causing some timeout issues. This patch splits the
testcase up by individual set algorithm.
libstdc++-v3:/ChangeLog:
* testsuite/25_algorithms/pstl/alg_sorting/set.cc: Delete
file.
* testsuite/25_algorithms/pstl/alg_sorting/set_difference.cc:
New file.
* testsuite/25_algorithms/pstl/alg_sorting/set_intersection.cc:
Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc:
Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/set_union.cc:
Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/set_util.h:
Likewise.
These tests fail with -std=gnu++98/-D_GLIBCXX_DEBUG in the runtest
flags. They should require the c++11 effective target.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/forward_list/debug/iterator1_neg.cc:
Skip as UNSUPPORTED for C++98 mode.
* testsuite/23_containers/forward_list/debug/iterator3_neg.cc:
Likewise.
libstdc++-v3/ChangeLog:
PR libstdc++/110542
* include/bits/stl_uninitialized.h (__uninitialized_default_n):
Do not use std::fill_n during constant evaluation.
Similar to r14-2052-gdd2eb972a5b063, replace the try-block with RAII
types for deallocating storage and destroying elements.
libstdc++-v3/ChangeLog:
* include/bits/vector.tcc (_M_default_append): Replace try-block
with RAII types.
The <syncstream> header is only supported for the cxx11 ABI. The
declarations of basic_syncbuf, basic_osyncstream, syncbuf and
osyncstream were already correctly guarded by a check for
_GLIBCXX_USE_CXX11_ABI, but the wsyncbuf and wosyncstream declarations
were not.
libstdc++-v3/ChangeLog:
* testsuite/27_io/headers/iosfwd/synopsis.cc: Make wsyncbuf and
wosyncstream depend on _GLIBCXX_USE_CXX11_ABI.
This reapplies r10-1314-g32bab8b6ad0a90 which was lost in the recent
PSTL rebase from upstream.
* include/pstl/pstl_config.h (_PSTL_PRAGMA_SIMD_SCAN,
_PSTL_PRAGMA_SIMD_INCLUSIVE_SCAN, _PSTL_PRAGMA_SIMD_EXCLUSIVE_SCAN):
Define to OpenMP 5.0 pragmas even for GCC 10.0+.
(_PSTL_UDS_PRESENT): Define to 1 for GCC 10.0+.
These calls should be qualified to prevent ADL, which can cause errors
for incomplete types that are associated classes.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (_Destroy): Qualify call.
* include/bits/stl_construct.h (_Destroy, _Destroy_n): Likewise.
* testsuite/23_containers/vector/cons/destroy-adl.cc: New test.
The addition of the multiply_defined suppress flag has been handled for some
considerable time now in the Darwin specs; remove it from the testsuite libs.
Avoid duplicates in the specs.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/ChangeLog:
* config/darwin.h: Avoid duplicate multiply_defined specs on
earlier Darwin versions with shared libgcc.
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp: Remove additional flag handled
by Darwin specs.
gcc/testsuite/ChangeLog:
* lib/g++.exp: Remove additional flag handled by Darwin specs.
* lib/obj-c++.exp: Likewise.
The __has_attribute(init_priority) check in <iostream> is true for Clang
on darwin, which means that user code including <iostream> thinks the
library will initialize the global streams. However, when libstdc++ is
built by GCC on darwin, the __has_attribute(init_priority) check is
false, which means that the library thinks that user code will do the
initialization when <iostream> is included. This means that the
initialization is never done.
Add an autoconf check so that the header and the library both make their
decision based on the static properties of GCC at build time, with a
consistent outcome.
As a belt and braces check, also do the initialization in <iostream> if
the compiler including that header doesn't support the attribute (even
if the library also containers the initialization). This might result in
redundant initialization done in <iostream>, but ensures the
initialization happens somewhere if there's any doubt about the
attribute working correctly due to missing linker support.
libstdc++-v3/ChangeLog:
PR libstdc++/110432
* acinclude.m4 (GLIBCXX_CHECK_INIT_PRIORITY): New.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_INIT_PRIORITY.
* include/std/iostream: Use new autoconf macro as well as
__has_attribute.
* src/c++98/ios_base_init.h: Use new autoconf macro instead of
__has_attribute.
Reviewed-by: Patrick Palka <ppalka@redhat.com>
This newly-introduced variable isn't used on all paths, so add the
[[maybe_unused]] attribute.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (random_device::_M_init): Add maybe_unused
attribute.
In r14-289-gf9412cedd6c0e7 I made the std::random_device constructor
throw std::system_error for unrecognized tokens. But it still throws
std::runtime_error for a token such as "rdseed" that is recognized but
not supported at runtime by the CPU the program is running on.
With this change we throw std::system_error for those cases too. This
fixes the following failures on Intel CPUs withour rdseed support:
FAIL: 26_numerics/random/random_device/94087.cc execution test
FAIL: 26_numerics/random/random_device/cons/token.cc execution test
FAIL: 26_numerics/random/random_device/entropy.cc execution test
libstdc++-v3/ChangeLog:
PR libstdc++/105081
* src/c++11/random.cc (random_device::_M_init): Throw
std::system_error when the requested device is a valid token but
not available at runtime.
The fix was overwritten by r14-2109-g3162ca09dbdc2e "libstdc++:
Synchronize PSTL with upstream".
libstdc++-v3:
PR libstdc++/108672
* include/pstl/unseq_backend_simd.h (__simd_or): Re-apply using
__INT32_TYPE__ instead of int32_t.
Building libstdc++ reportedly fails for targets without lock-free
std::atomic<T*> which don't define __GTHREAD_MUTEX_INIT:
src/c++20/tzdb.cc:110:21: error: 'constinit' variable 'std::chrono::{anonymous}::list_mutex' does not have a constant initializer
src/c++20/tzdb.cc:110:21: error: call to non-'constexpr' function 'std::mutex::mutex()'
The solution implemented by this commit is to use a local static mutex
when it can't be constinit, so that it's constructed on first use.
With this change, we can also simplify the preprocessor logic for
defining USE_ATOMIC_SHARED_PTR. It now depends on the same conditions as
USE_ATOMIC_LIST_HEAD, so in theory we could have a single macro. Keeping
them separate would allow us to replace the use of atomic<shared_ptr<T>>
with a mutex if that performs better, without having to give up on the
lock-free cache for fast access to the list head.
libstdc++-v3/ChangeLog:
* src/c++20/tzdb.cc (USE_ATOMIC_SHARED_PTR): Define consistently
with USE_ATOMIC_LIST_HEAD.
(list_mutex): Replace global object with function. Use local
static object when std::mutex constructor isn't constexpr.
Although the copy_file_range(2) man page shows the arguments as off64_t*
that is not portable. For musl there is no off64_t type, as off_t is
always 64-bit. Use the loff_t type which is always 64-bit even if off_t
isn't. We could just use off_t because the filesystem library is
compiled with _FILE_OFFSET_BITS=64, but loff_t is the more correct type
for this interface.
libstdc++-v3/ChangeLog:
PR libstdc++/110462
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check that
copy_file_range can be called with loff_t* arguments.
* configure: Regenerate.
* src/filesystem/ops-common.h (copy_file_copy_file_range):
Use loff_t for offsets.
The libstdc++ test suite checks whether gdb type printers are
available like so:
set do_whatis_tests [gdb_batch_check "python print(gdb.type_printers)" \
"\\\[\\\]"]
This regexp assumes that the list of printers is empty. However,
sometimes it's convenient to ship a gdb that comes with some default
printers, causing this to erroneously report that gdb is "too old".
I believe the intent of this check is to ensure that gdb.type_printers
exists -- not to check its starting value. This patch changes the
check to accept any Python list as output.
Note that the patch doesn't look for the trailing "]". I tried this
but in my case the output was too long for expect. It seemed fine to
just check the start, as the point really is to reject the case where
the command prints an error message.
libstdc++-v3/ChangeLog
* testsuite/lib/gdb-test.exp (gdb-test): Relax type-printer
regexp.
PR middle-end/109849
* include/bits/c++config (std::__terminate): Mark cold.
* include/bits/functexcept.h: Mark everything as cold.
* libsupc++/exception: Mark terminate and unexpected as cold.
The formatter for pointers was casting to uint64_t which sign extends a
32-bit pointer and produces a value that won't fit in the provided
buffer. Cast to uintptr_t instead.
There was also a bug in the __parse_integer helper when converting a
wide string to a narrow string in order to use std::from_chars on it.
The function would always try to read 32 characters, even if the format
string was shorter than that. Fix that bug, and remove the constexpr
implementation of __parse_integer by just using __from_chars_alnum
instead of from_chars, because that's usable in constexpr even in
C++20.
libstdc++-v3/ChangeLog:
PR libstdc++/110239
* include/std/format (__format::__parse_integer): Fix buffer
overflow for wide chars.
(formatter<const void*, C>::format): Cast to uintptr_t instead
of uint64_t.
* testsuite/std/format/string.cc: Test too-large widths.
This was recently approved for C++26, but there's no harm in
implementing it unconditionally for C++20 and C++23. As it says in the
paper, it doesn't change the meaning of any valid code. It only enables
things that were previously ill-formed for questionable reasons.
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (projected): Replace class
template with alias template denoting an ADL-proofed helper.
(incremental_traits<projected<Iter, Proj>>): Remove.
* testsuite/24_iterators/indirect_callable/projected-adl.cc:
New test.
These functions should be qualified to disable unwanted ADL.
The overload of __check_singular_aux for safe iterators was previously
being found by ADL, because it wasn't declared before __check_singular.
Add a declaration so that it can be found by qualified lookup.
libstdc++-v3/ChangeLog:
* include/debug/helper_functions.h (__get_distance)
(__check_singular, __valid_range_aux, __valid_range): Qualify
calls to disable ADL.
(__check_singular_aux(const _Safe_iterator_base*)): Declare
overload that was previously found via ADL.
Replace the try-block with RAII types for deallocating storage and
destroying elements.
libstdc++-v3/ChangeLog:
* include/bits/vector.tcc (_M_realloc_insert): Replace try-block
with RAII types.
rtems, like vxworks, uses fast-float doubles for from_chars even for
long double, so it loses precision, so expect the long double bits to
fail on aarch64.
for libstdc++-v3/ChangeLog
* testsuite/20_util/from_chars/4.cc: Skip long double on
aarch64-rtems.
When running the libstdc++ testsuite on AArch64 RTEMS, we noticed
that about 25 tests are failing during the link, due to the "sqrtl"
function being defined twice:
- once inside RTEMS' libm;
- once inside our libstdc++.
One test that fails, for instance, would be 26_numerics/complex/13450.cc.
In comparing libm and libstdc++, we found that libstc++ also
duplicates "hypotf", and "hypotl".
For "sqrtl" and "hypotl", the symbosl come a unit called
from math_stubs_long_double.cc, while "hypotf" comes from
the equivalent unit for the float version, called math_stubs_float.cc.
Those units are always compiled in libstdc++ and provide our own
version of various math routines when those are missing from
the target system. The definition of those symbols is predicated
on the existance of various macros provided by c++config.h, which
themselves are predicated by the corresponding HAVE_xxx macros
in config.h.
One key element behind what's happening, here, is that the target
uses newlib, and therefore GCC was configured --with-newlib.
The section of libstdc++v3's configure script that handles which math
functions are available has a newlib-specific section, and that
section provides a hardcoded list of symbols.
For "hypotf", this commit fixes the issue by doing the same
as for the other routines already declared in that section.
I verified by inspection in the newlib code that this function
should always be present, so hardcoding it in our configure
script should not be an issue.
For the math routines handling doubles ("sqrtl" and "hypotl"),
however, I do not believe we can assume that newlib's libm
will always provide them. Therefore, this commit fixes that
part of the issue by ading a compile-check for "sqrtl" and "hypotl".
And while at it, we also include checks for all the other math
functions that math_stubs_long_double.cc re-implements, allowing
us to be resilient to future newlib enhancements adding support
for more functions.
libstdc++-v3/ChangeLog:
* configure.ac ["x${with_newlib}" = "xyes"]: Define
HAVE_HYPOTF. Add compile-checks for various long double
math functions as well.
* configure: Regenerate.
The test wchar_t/94749.cc can take about 10 minutes on some
simulator/host combinations with char/94749.cc at a third of
that time. The cause is test05 which is quite heavy and
includes wrapping a 32-bit counter. Run it only for native
setups.
* testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc (main)
[! SIMULATOR_TEST]: Also exclude running test05.
* testsuite/27_io/basic_istream/ignore/char/94749.cc: Ditto.
Since the type_traits header is a C++11 header file, using can be used instead
of typedef. This patch provides more readability, especially for long type
names.
libstdc++-v3/ChangeLog:
* include/std/type_traits: Use using instead of typedef
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
When long double uses IEEE binary128 representation we define the
_Float128 overload of std::from_chars inline in <charconv>. My changes
in r14-1431-g7037e7b6e4ac41 cause it to also be defined non-inline in
the library, leading to an abi-check failure for (at least) sparc and
aarch64.
Suppress the definition in the library if long double and _Float128 have
are both IEEE binary128.
libstdc++-v3/ChangeLog:
PR libstdc++/110077
* src/c++17/floating_from_chars.cc (from_chars) <_Float128>:
Only define if _Float128 and long double have different
representations.
We can't define endpoints and resolvers without the relevant OS support.
If IPPROTO_TCP and IPPROTO_UDP are both udnefined then we won't need
basic_endpoint and basic_resovler anyway, so make them depend on those
macros.
libstdc++-v3/ChangeLog:
PR libstdc++/100285
* include/experimental/internet [IPPROTO_TCP || IPPROTO_UDP]
(basic_endpoint, basic_resolver_entry, resolver_base)
(basic_resolver_results, basic_resolver): Only define if the tcp
or udp protocols will be defined.
The addition of __cxa_call_terminate@@CXXABI_1.3.15 on trunk means we
need a new version.
libstdc++-v3/ChangeLog:
* acinclude.m4 (libtool_VERSION): Update to 6.0.33.
* configure: Regenerate.
* doc/xml/manual/abi.xml: Add libstdc++.so.6.0.33.
* doc/html/manual/abi.html: Regenerate.
I had intended to support the P2510R3 proposal unconditionally in C++20
mode, but I left it half implemented. The parse function supported the
new extensions, but the format function didn't.
This adds the missing pieces, and makes it only enabled for C++26 and
non-strict modes.
libstdc++-v3/ChangeLog:
PR libstdc++/110149
* include/std/format (formatter<const void*, charT>::parse):
Only alow 0 and P for C++26 and non-strict modes.
(formatter<const void*, charT>::format): Use toupper for P
type, and insert zero-fill characters for 0 option.
* testsuite/std/format/functions/format.cc: Check pointer
formatting. Only check P2510R3 extensions conditionally.
* testsuite/std/format/parse_ctx.cc: Only check P2510R3
extensions conditionally.
As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence<N...> and then create a very large
aggregate initializer from the pack expansion. For trivial types we can
simply default-initialize the std::array and then use memcpy to copy the
values. For non-trivial types we need to use the existing
implementation, despite the compilation cost.
As also noted in the PR, using a generic lambda instead of the
__to_array helper compiles faster since gcc-13. It also produces
slightly smaller code at -O1, due to additional inlining. The code at
-Os, -O2 and -O3 seems to be the same. This new implementation requires
__cpp_generic_lambdas >= 201707L (i.e. P0428R2) but that is supported
since Clang 10 and since Intel icc 2021.5.0 (and since GCC 10.1).
libstdc++-v3/ChangeLog:
PR libstdc++/110167
* include/std/array (to_array): Initialize arrays of trivial
types using memcpy. For non-trivial types, use lambda
expressions instead of a separate helper function.
(__to_array): Remove.
* testsuite/23_containers/array/creation/110167.cc: New test.
Our existing tests for std::deque::emplace, std::list::emplace and
std::vector::emplace are poor. We only have compile tests for PR 52799
and the equivalent for a const_iterator as the insertion point. This
fails to check that the value is actually inserted correctly and the
right iterator is returned.
Add new tests that cover the existing 52799.cc and const_iterator.cc
compile-only tests, as well as verifying the effects are correct.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/deque/modifiers/emplace/52799.cc:
Removed.
* testsuite/23_containers/deque/modifiers/emplace/const_iterator.cc:
Removed.
* testsuite/23_containers/list/modifiers/emplace/52799.cc:
Removed.
* testsuite/23_containers/list/modifiers/emplace/const_iterator.cc:
Removed.
* testsuite/23_containers/vector/modifiers/emplace/52799.cc:
Removed.
* testsuite/23_containers/vector/modifiers/emplace/const_iterator.cc:
Removed.
* testsuite/23_containers/deque/modifiers/emplace/1.cc: New
test.
* testsuite/23_containers/list/modifiers/emplace/1.cc: New
test.
* testsuite/23_containers/vector/modifiers/emplace/1.cc: New
test.
This test apparently contains 3 problematic floating point constants,
1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
when -fexcess-precision=standard evaluates double constants in the precision
of Intel extended 80-bit long double.
As written in the PR, e.g. the first one is
0x1.7a2ecc414a03f7ff6ca1cb527787b130a97d51e51202365p+418
in the precision of GCC's internal format, 80-bit long double has
63-bit precision, so the above constant rounded to long double is
0x1.7a2ecc414a03f800p+418L
(the least significant bit in the 0 before p isn't there already).
0x1.7a2ecc414a03f800p+418L rounded to IEEE double is
0x1.7a2ecc414a040p+418.
Now, if excess precision doesn't happen and we round the GCC's internal
format number directly to double, it is
0x1.7a2ecc414a03fp+418 and that is the number the test expects.
One can see it on x86-64 (where excess precision to long double doesn't
happen) where double(1e126L) != 1e126.
The other two constants suffer from the same problem.
The following patch tweaks the testcase, such that those problematic
constants are used only if FLT_EVAL_METHOD is 0 or 1 (i.e. when we have
guarantee the constants will be evaluated in double precision),
plus adds corresponding tests with hexadecimal constants which don't
suffer from this excess precision problem, they are exact in double
and long double can hold all double values.
2023-06-07 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/110145
* testsuite/20_util/to_chars/double.cc: Include <cfloat>.
(double_to_chars_test_cases,
double_scientific_precision_to_chars_test_cases_2,
double_fixed_precision_to_chars_test_cases_2): #if out 1e126, 4.91e-6
and 5.547e-6 tests if FLT_EVAL_METHOD is negative or larger than 1.
Add unconditional tests with corresponding double constants
0x1.7a2ecc414a03fp+418, 0x1.4981285e98e79p-18 and
0x1.7440bbff418b9p-18.
In r14-1583-g192665feef7129 I meant to add CXXABI_1.3.15 but instead I
replaced CXXABI_1.3.14 with it. This restores the CXXABI_1.3.14 version.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc (check_version): Re-add
CXXABI_1.3.14.
GCC Administrator