Clock calls on VxWorks are slow, so the odds that the consecutive
calls of *clock::now() will yield a different result are not
negligible. Reordering the calls avoids false positives.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/semaphore/try_acquire_until.cc
(test01): Reorder calls.
I noticed that Doxygen was not documenting the contents of
<experimental/simd> as part of namespace std, because it didn't know
about the _GLIBCXX_SIMD_BEGIN_NAMESPACE and _GLIBCXX_SIMD_END_NAMESPACE
macros which open and close namespace std::experimental::parallelism_v2.
After defining those macros in the Doxygen config, the Doxygen comments
in experimental/bits/simd.h were causing namespace std to be documented
as part of the Parallelism TS v2. That's because the preprocessed code
looks like:
/** @ingroup ts_simd
* @{
*/
namespace std::experimental::inline parallelism_v2 {
This causes Doxygen to apply the @ingroup command to all three of
namespace std, namespace std::experimental, and namespace
std::experimental::parallelism_v2. I don't know if this is the intended
behaviour, but it doesn't seem useful so I've opened an issue about it:
https://github.com/doxygen/doxygen/issues/12114
To workaround this, we can move the _GLIBCXX_SIMD_BEGIN_NAMESPACE macro
before the @{ group and document it separately with a @namespace
comment. That makes the @ingroup only apply to the namespace named by
the @namespace command, not to its enclosing namespaces as well. Moving
the position of the BEGIN macro also fixes the nesting, as previously we
had @{ then BEGIN then @} then END. Now we have BEGIN @{ @} END which
seems preferable.
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (PREDEFINED): Add BEGIN/END macros for
the <experimental/simd> namespace.
* include/experimental/bits/simd.h: Move BEGIN macro before
Doxygen @{ group.
Use markdown and suppress unwanted docs for internal helpers.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h: Prevent Doxygen from documenting
namespace __detail as part of the Iterators topic.
* include/bits/stl_iterator_base_funcs.h: Likewise. Also mark
internal helpers as undocumented.
(distance, advance): Improve Doxygen comments.
* include/bits/stl_iterator_base_types.h (iterator): Use
markdown in Doxygen comment. Add @deprecated.
(iterator_traits): Improve wording of Doxygen comment.
The ranges::sample and ranges::shuffle algorithms are supposed to work
with types which model std::uniform_random_bit_generator, which means
they should not assume that G::result_type is present. That isn't needed
to satisfy the concept. Change the algorithms to use decltype(__g())
instead of using result_type.
This isn't sufficient to fix the bug though, because those algorithms
use std::uniform_int_distribution and that class template's operator()
overloads depend on the more restrictive uniform random bit generator
requirements, which do include the presence of a nested result_type
member.
We need to change std::uniform_int_distribution to also use decltype
instead of the nested result_type, even though the standard says that
std::uniform_int_distribution is allowed to assume that result_type
exists.
There's yet another problem, which is that a type that returns random
bool values can model the concept, but doesn't meet the named
requirements and can't be used with std::uniform_int_distribution. That
isn't addressed by this change.
libstdc++-v3/ChangeLog:
PR libstdc++/121919
* include/bits/ranges_algo.h (__sample_fn, __shuffle_fn): Use
decltype(__g()) instead of remove_reference_t<_G>::result_type.
* include/bits/uniform_int_dist.h
(uniform_int_distribution::operator()): Use decltype(__urng())
instead of _UniformRandomBitGenerator::result_type
(uniform_int_distribution::__generate_impl): Likewise.
* testsuite/25_algorithms/sample/121919.cc: New test.
* testsuite/25_algorithms/shuffle/121919.cc: New test.
Reviewed-by: Nathan Myers <nmyers@redhat.com>
The <ranges> header was added to the freestanding headers in
r16-3575-g1a41e52d7ecb58 but bits/binders.h that it depends on was not
moved, making <ranges> unusable with --disable-libstdcxx-hosted.
libstdc++-v3/ChangeLog:
PR libstdc++/125112
* include/Makefile.am: Move bits/binders.h from bits_headers to
bits_freestanding.
* include/Makefile.in:
This expands on the changes from test fix r16-6710-gda5a5c55284969:
* test name now reflect the size of the generator range,
* extracted code repeated between tests was exctracted to run_generator,
* expanded non-power of two ranges types to cover all IEC559 floating point,
* select values to test based on the size of mantisa instead of type,
handling different long double representations.
The test now cover the cases, where mutliple value greater than one are
produced (and skipped) in the row. To avoid test running infinite loop,
the number of skips per element is limited by max_skips_per_elem template
parameter of run_generator.
The values checked in test_2p31m1<double> differs from their old test03<double>
counterpart, as we now request mantissa - 5 bits for each type (48bits for
ieee64) instead of previously hardoced 30bits.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Updated tests.
Reviewed-by: Nathan Myers <ncm@cantrip.org>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Coverage for LWG 4480, "<stdatomic.h> should provide ATOMIC_CHAR8_T_LOCK_FREE".
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/headers/stdatomic.h/macros.cc:
Copy of ../atomic/macros.cc with header include changed.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Various simd_x86 functions that handle double need to be adjusted to
match 64-bit long double as well.
Introduce __is_x86_ps<_Tp>() and __is_x86_pd<_Tp>() and use them
instead of is_same_v<_Tp, float> and is_same_v<_Tp, double>,
respectively.
for libstdc++-v3/ChangeLog
PR libstdc++/124657
* include/experimental/bits/simd_x86.h
(__is_x86_ps<_Tp>): New. Replace is_same_v<_Tp, float> with it.
(__is_x86_pd<_Tp>): New. Replace is_same_v<_Tp, double> with it.
When long double is as wide as double on x86 (-mlong-double-64), make
the __intrinsic_type a vector of double.
for libstdc++-v3/ChangeLog
PR libstdc++/124657
* include/experimental/bits/simd.h (__intrinsic_type::type):
Map long double to double.
There's a comment from 2002 suggesting that
numeric_limits<bool>::traps was in a DR, but C++ standards including
11, 17 and 23 explicitly set it to false, presumably in response to
issue 184.
Issue 554 clarifies that traps is about values that may trap, rather
than operations that may trap, so we were wrong in the interpretation
about divide-by-zero operations' trapping on integral types that led
to __glibcxx_integral_traps's defaulting to true, and some of its
overrides.
Align numeric_limits<bool>::traps with the standard, default
__glibcxx_integral_traps to false, drop the overriders based on the
incorrect interpretation, but keep __glibcxx_integral_traps to allow
command-line restoring of this ABI fix, and for the admittedly
unlikely case of trapping integral values' coming to exist on some
architecture.
for libstdc++-v3/ChangeLog
* include/std/limits (__glibcxx_integral_traps): Set to
false. Update comments.
(numeric_limits<bool>::traps): Drop comments.
* config/cpu/arm/cpu_defines.h: Remove.
* config/cpu/powerpc/cpu_defines.h: Likewise.
* configure.host (cpu_defines_dir): Adjust.
This hasn't been updated to reflect the new features in GCC 16 (and one
that was backported to gcc-15 for GCC 15.3 but not released yet).
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Update status table.
* doc/html/manual/status.html: Regenerate.
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml (Flags): Update description of
default value for -std option.
* doc/html/manual/using.html: Regenerate.
This resolves LWG3454, "pointer_traits::pointer_to should be constexpr",
accepted in Kona 2025.
The change is applied since C++20, i.e. standard in which pointer_to
was made constexpr for T* specialization.
libstdc++-v3/ChangeLog:
* include/bits/ptr_traits.h (__ptr_traits_ptr_to::pointer_to):
Define as constexpr since C++20.
* testsuite/20_util/pointer_traits/pointer_to_constexpr.cc:
New test for custom pointer-like type.
Expanded test coverage to include:
* array of unknown bounds
* function types and pointers
* data and function member pointers
libstdc++-v3/ChangeLog:
* testsuite/18_support/comparisons/type_order/1.cc: Add tests
for more type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/type-order1.C: Add tests for more type.
Reviewed-by: Jakub Jelinek <jakub@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
https://eel.is/c++draft/basic.types.general#9.sentence-1 says that
std::meta::info and its cv-qualified versions are scalar types too
(and in https://eel.is/c++draft/basic.fundamental#19.sentence-1
that they are fundamental types too).
Now, on the reflection side, eval_is_scalar_type is handled
in the compiler and uses SCALAR_TYPE_P (type) which includes
REFLECTION_TYPE_P check and eval_is_fundamental_type includes that
explicitly too.
std::is_fundamental uses
template<typename _Tp>
struct is_fundamental
: public __or_<is_arithmetic<_Tp>, is_void<_Tp>,
is_null_pointer<_Tp>
#if __cpp_impl_reflection >= 202506L
, is_reflection<_Tp>
#endif
>::type
{ };
but for std::is_scalar we apparently forgot to include is_reflection.
The following patch fixes that.
2026-04-26 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/125024
* include/std/type_traits (std::is_scalar): For
__cpp_impl_reflection >= 202506L handle is_reflection types as
scalar.
* testsuite/20_util/is_scalar/reflection.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Resolves LWG3797, "elements_view insufficiently constrained".
When P2165R4 updated __has_tuple_element in C++23 to reuse __tuple_like
concept, it dropped the requirement of validity of get, assuming that for
tuple_like type with size of N, get<I> on lvalue is well-formed for any I < N.
This however does not hold for ranges::subrange (tuple-like of size 2) with
move-only iterator, for which get can only be applied on rvalue. In consequence
constrains allowed instantiating elements_view for range of such subrange,
but instantiating it's iterator lead to hard error from iterator_category
computation.
This patch applies the requirements on validity of get also in C++23 and
later standard modes.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__has_tuple_element): Check
if std::get<_Nm>(__t) returns referenceable type also for C++23
and later.
* testsuite/std/ranges/adaptors/elements.cc: Add test covering
vector of ranges::subrange with move-only iterator.
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Resolves LWG4096, views::iota(views::iota(0)) should be rejected.
For __e of type _Tp that is specialization of iota_view, the CTAD based
expression iota_view(__e) is well formed, and creates a copy of __e.
As iota_view<decay_t<_Tp>> is ill-formed in this case (iota_view is not
weakly_incrementable), using that type in return type explicitly, removes
the overload from overload resolution in this case.
The (now redudant) __detail::__can_iota_view constrain in template head is
preserved, to provide error messages consistent with adaptors for other
non-incrementable types.
libstdc++-v3/ChangeLog:
* include/std/ranges (_Iota::operator()(_Tp&&)): Replace
auto return type and CTAD with iota_view<decay_t<_Tp>>.
* testsuite/std/ranges/iota/iota_view.cc: Tests if
views::iota(iota_view) is rejected.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This resolves LWG 4098, "views::adjacent<0> should reject non-forward ranges"
which was approved in Sofia 2024.
libstdc++-v3/ChangeLog:
* include/std/ranges (_AdjacentTransform::operator())
(_Adjacent::operator()): Require forward_range for N == 0.
* testsuite/std/ranges/adaptors/adjacent/1.cc: Test if input_ranges
are rejected.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc: Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
The LWG4083, "views::as_rvalue should reject non-input ranges" is resolved,
as input_range<_Range> is implied by __detail::__can_as_rvalue_view<_Range>.
libstdc++-v3/ChangeLog:
* include/std/ranges: Add comment for LWG4083.
This resolves LWG 4253, "basic_const_iterator should provide iterator_type"
which was approved in Kona 2025.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (basic_const_iterator::iterator_type):
Define.
* testsuite/24_iterators/const_iterator/1.cc: Tests for
iterator_type.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Import the new 2026a tzdata.zi file and new leapseconds expiry date.
libstdc++-v3/ChangeLog:
* include/std/chrono (chrono::__detail::__get_leap_second_info):
Update expiry date for leap seconds list.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds):
Likewise.
* src/c++20/tzdata.zi: Import new file from 2026a release.
This expands the resolution of LWG4325 to heterogenous comparision
with T per standard draft (see corresponding commit [1]).
[1] 833d635d64
libstdc++-v3/ChangeLog:
* include/bits/indirect.h (indirect::operator==): Adjust
noexcept specification.
* testsuite/std/memory/indirect/relops.cc: New test for noexcept
specification.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This implements LWG4486. integral-constant-like and constexpr-wrapper-like
exposition-only concept duplication.
libstdc++-v3/ChangeLog:
* include/bits/simd_details.h (simd::__constexpr_wrapper_like):
Move to...
* include/std/concepts (std::__constexpr_wrapper_like): Moved
from bits/simd_details.h.
* include/std/span (std::__integral_constant_like): Define in
terms of __constexpr_wrapper_like.
* testsuite/std/simd/traits_impl.cc: Added using declaration
for std::__constexpr_wrapper_like.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Both __cpp_impl_reflection and __cpp_lib_reflection were increased from
202506L to 202603L post Croydon, I assume to show that P3795R2 (maybe some
issues too) have been implemented.
Now, we do implement P3795R2 except for the is_applicable_type,
is_nothrow_applicable_type and apply_result metafunctions, but Jonathan says
there is agreement in LWG that to test for availability of those one should
test __cpp_lib_reflection >= 202603L && __cpp_lib_apply >= 202603L.
So, this patch bumps both FTMs.
2026-04-22 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_impl_reflection value
from 202506L to 202603L.
gcc/testsuite/
* g++.dg/DRs/dr2581-2.C: Adjust for __cpp_impl_reflection bump from
202506L to 202603L.
* g++.dg/reflect/feat1.C: Likewise. Also adjust for
__cpp_lib_reflection bump from 202506L to 202603L.
* g++.dg/reflect/feat2.C: Likewise.
* g++.dg/reflect/feat3.C: Likewise.
libstdc++-v3/
* include/bits/version.def (reflection): Bump 202506L to 202603L
for both v and in extra_cond.
* include/bits/version.h: Regenerate.
* include/std/meta: Compare __glibcxx_reflection against
202603L rather than 202506L.
* src/c++23/std.cc.in: Likewise.
Reviewed-by: Jason Merrill <jason@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
This implements LWG4290. Missing Mandates clauses on is_sufficiently_aligned.
libstdc++-v3/ChangeLog:
* include/bits/align.h (is_sufficiently_aligned): Mandate
that _Align is power of two.
* testsuite/20_util/is_sufficiently_aligned/2_neg.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This makes the deduction guide accepting data_handle_type, mapping
and accessor consistent with corresponding constructor.
Resolves LWG4511.
libstdc++-v3/ChangeLog:
* include/std/mdspan (mdspan): Remove reference from
_AccessorType::data_handle_type parameteter of deduction
guide.
* testsuite/23_containers/mdspan/mdspan.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This covers issue affecting pre-C+26 features that were resolved
during 2026 Croydon meeting.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h: Add comment for LWG3831.
* include/bits/print.h: Add comment for LWG4549.
* include/std/condition_variable: Add comment for LWG3504.
* include/std/format: Add comments for LWG4522.
* include/std/mdspan: Add comment for LWG4314.
* include/std/optional: Add comment for LWG2746.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
allocator_traits<>::allocate_at_least has taken its allocator
by value, incorrectly. This patch makes it take its allocator
by reference, as specified.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (allocate_at_least):
Take allocator argument by reference, per Standard.
The comment describes an earlier version of the function which I
experimented with when implementing the std::print feature. Update it to
describe the current semantics.
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__open_terminal): Fix comment.
We emit -Wmissing-field-initializers warnings for code like
data_member_spec (^^int, { .name = "dms" })
which seems undesirable. We can initialize the members of
std::meta::data_member_options to suppress that warning (clang's <meta>
has these initializers too).
PR c++/124950
libstdc++-v3/ChangeLog:
* include/std/meta (std::meta::data_member_options): Initialize
alignment, bit_width, and annotations members.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/data_member_spec7.C: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
This defines __platform_wait_t as unsigned int for OpenBSD and
DragonFly. This means that std::semaphore will use unsigned int by
default, and so will benefit from more efficient wait/notify ops if we
start to use the OpenBSD futex(2) syscall or the DragonFly umtx(2)
syscalls. We don't currently use them, but if we start to in future, it
would be an ABI break to change __platform_wait_t later.
libstdc++-v3/ChangeLog:
PR libstdc++/120527
* include/bits/atomic_wait.h [__OpenBSD__ || __DragonFly]: Use
unsigned int for __platform_wait_t.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Darwin has kernel support for this facility from 10.12 (macOS Sierra).
From 10.15 (macOS Catalina) 64bit qualitities are supported.
When the library is built for 10.12+ both 32b and 64b quantities will be
supported by the DSO which means it can be installed on 10.12+ with support
for 64bit available when the instalation is >= 10.15.
The header will only recognise 64b quantities when the deployment version
is >= 10.15.
If the library is built for <= 10.11, the support will be missing and attempts
to use it wlll result in link errors.
The platform wait type is unconditionally set to 32bits, since this is compatible
across supported OS editions.
PR libstdc++/120527
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h:
* src/c++20/atomic.cc (__ulock_wait): Enable supported Darwin versions.
(__ulock_wake): Likewise.
(UL_COMPARE_AND_WAIT): New.
(UL_COMPARE_AND_WAIT64): New.
(ULF_WAKE_ALL): New.
(_GLIBCXX_HAVE_PLATFORM_WAIT): Enable for suppported Darwin versions.
Co-authored-by: Iain Sandoe <iain@sandoe.co.uk>
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
P3844R2 added consteval conversion for value-preserving conversion from
constants. It had been approved by LEWG in Kona. Therefore, the current
implementation has the consteval broadcast constructor. In Croydon, LEWG
reversed the decision but changed the overload set to keep the design
space open for C++29.
This patch implements the removal of the consteval constructor and
changes the broadcast constructor according to P4012R1, to keep the
design space open.
libstdc++-v3/ChangeLog:
* include/bits/simd_details.h (__value_preserving_cast): Remove.
* include/bits/simd_mask.h (basic_mask): Replace plain 0 and 1
literals with cw<0> and cw<1>. Replace explicit basic_vec
construction from 0 and 1 with default init and broadcast from
_Up(1).
(_M_to_uint): Replace 1 with cw<1>.
* include/bits/simd_vec.h (basic_vec): Remove consteval
broadcast overload. Remove explicit broadcast from
non-value-preserving types.
* testsuite/std/simd/arithmetic.cc: Replace ill-formed integer
literals with explicit cast to T or use cw.
* testsuite/std/simd/mask.cc: Likewise.
* testsuite/std/simd/simd_alg.cc: Likewise.
* testsuite/std/simd/traits_common.cc: Adjust for resulting
traits changes.
* testsuite/std/simd/traits_math.cc: Likewise.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
It turns out a union without an active member does not violate C++20 core
constant expression rules and r16-8748 was really just a workaround for a
front end bug. The actual underlying problem -- that the constexpr
evaluator treated an explicitly destroyed union member as still active --
has been fixed by r16-8767 which makes this workaround unnecessary for GCC.
Rather than remove the workaround, restrict it to Clang which seems to have
a similar bug making it still needed for e.g. the r16-8748 testcase.
PR c++/124910
libstdc++-v3/ChangeLog:
* include/std/optional (_Optional_payload_base::_M_destroy):
Restrict r16-8748 workaround to Clang, and adjust comment.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
This change to the macro was done intentionally to quickly test that the
changes in r16-8720-g209550a04e143e did not break the code in the #else
branch, but it was not supposed to be committed!
libstdc++-v3/ChangeLog:
* include/bits/print.h: Fix spelling of macro.
When an optional that contains a value is cleared, _M_destroy invokes the
destructor of the contained value _Storage::_M_value, leaving the union
_Storage without an active member. While this is benign at runtime, a
union suboject with no active member violates core constant expression
requirements and in turn an optional in this state can't be used as a
constant initializer, which Clang and recent GCC (since r16-3022) correctly
diagnose.
To fix this, this patch makes _M_destroy activate the dummy union member
_M_empty after destroying _M_value to ensure that the union always has
an active member throughout its lifetime. We use std::construct_at
instead of simple assignment to work around a front end bug (comment #3
in the PR). Doing so means we don't activate the member in C++17 mode,
which should be fine; I don't think it's possible to disengage an engaged
optional using only the C++17 constexpr optional operations.
PR c++/124910
libstdc++-v3/ChangeLog:
* include/std/optional (_Optional_payload_base::_M_destroy)
[__cpp_lib_optional >= 202106L]: During constant evaluation,
after invoking destructor of _M_value, use construct_at to
activate _M_empty.
* testsuite/20_util/optional/constexpr/124910.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
