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:
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 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.
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.
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>
Like in r16-559 for std::expected, std::indirect's operator== is also
prone to constraint recursion due to CWG 2369, for the Mandates that we
implement as an associated constraint. This patch works around the
recursion in a similar manner as done for std::expected (and
std::basic_const_iterator).
PR libstdc++/124890
PR libstdc++/119714
PR libstdc++/112490
libstdc++-v3/ChangeLog:
* include/bits/indirect.h (indirect::operator==): Replace
non-dependent std::indirect function parameter with a
dependent one of type indirect<_Vp> where _Vp matches _Tp.
* testsuite/std/memory/indirect/124890.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
We don't want to export std::vprint_unicode etc. from libstdc++.so yet,
but we can give users the option of improving compile times by getting
the definitions of the std::print internals from libstdc++exp.a instead.
This commit adds a macro, _GLIBCXX_NO_INLINE_PRINT, which disables the
inline definitions of std::vprint_unicode etc. so that extern
definitions in libstdc++exp.a can be used instead.
With this change compiling a helloworld using std::print goes from 8s to
under 2s with trunk. For release branches with --enable-checking=release
we should see even faster times. The object file size is also
dramatically smaller, because there's just a single call to an extern
function instead of instantiating the entire std::print and std::format
implementation inline.
libstdc++-v3/ChangeLog:
PR libstdc++/124410
* doc/html/*: Regenerate.
* doc/xml/manual/using.xml (_GLIBCXX_NO_INLINE_PRINT): Document
macro.
* include/Makefile.am: Add bits/print.h and bits/ostream_print.h
headers.
* include/Makefile.in: Regenerate.
* include/std/ostream (vprint_nonunicode, vprint_unicode): Move
definitions to new bits/ostream_print.h header.
* include/std/print (__format::_File_sink, vprint_nonunicode)
(vprint_nonunicode_buffered, vprint_unicode)
(vprint_unicode_buffered): Move definitions to new bits/print.h
header.
* src/c++23/print.cc: Include new headers to define symbols for
inline print functions.
* include/bits/ostream_print.h: New file.
* include/bits/print.h: New file.
This patch extracts a __format::__do_vformat_to for the _Sink_iter
(and matching format context) and exports explicit instantiations
of it for char and wchar_t. As every format function is implementing
as delegating to one of these overloads, this significantly reduces
the compilation time.
Instantiating __format::__do_vformat_to triggers specializations of
formatters for types stored in basic_format_arg directly (arithmetic
types, strings). In case when their behavior depends on the TU specific
configuration, only one configuration can be exported from shared
lib. In case of beforementioned formatters:
* ? (debug mode) is accepted in for strings and characters
* multibyte utf-8 encoded character is accepted as fill when the
literal encoding is Unicode.
The first issue is addressed by this patch, by declaring extern
definition only for the C++20. We will need to reconsider how to
handle the specifiers when C++23 becomes stable.
The literal encoding is handled by adding a second template parameter
to __do_vformat_to overload, that is initialized with 1 if literal
encoding is Unicode (the parameter has unsigned type to allow more
information to be encoded). This allows library to export implementation
for Unicode literal encoding (format-inst.cc is compiled with appropriate
flag), by declaring extern specialization only for value 1.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4): Exclude exports
of std::basic_fo* (matching basic_format_context).
(GLIBCXX_3.4.35): Export __format::__do_vformat_to
specializations for _Sink_iter and char/wchar_t.
* include/std/format: (__format::__do_vformat_to):
Extract overload accepting _Sink_iter and provide extern
explicit specialization for char/wchar_t in C++20 mode.
* src/c++20/Makefile.am: Add format-inst.cc.
* src/c++20/Makefile.in: Regenerate.
* src/c++20/format-inst.cc: New file defining explicit
instantiation.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
The philox counter increment that happens in
philox_engine::_M_transition(), applies +1 to _M_x[0] before the bitwise
OR with (_M_x[1] << __w), so the carry from _M_x[0] is merged into the
_M_x[1] portion rather than being added to it. This causes the counter
to cycle prematurely and never advance past {0, 0, 1, 2^w - 1}.
Fix by changing operations order, which results in forming the
full-width value from _M_x[1]:_M_x[0] and then adding 1 on both the n ==
4 and n == 2 paths.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (philox_engine::_M_transtiion): Fix
counter increment to propagate carry correctly.
* testsuite/26_numerics/random/philox_engine/operators/counter_carry.cc:
New test.
Signed-off-by: Elena Tyuleneva <elena.tyuleneva@intel.com>
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
While testing a patch for std::philox_engine I noticed that
instantiating std::philox_engine with n=2 and w=64 fails on targets
without __int128, because it relies on an implicit conversion from the
intermediate counter type to the result type. When w=64 and the target
doesn't support __int128, we use the __rand_uint128 class type for the
intermediate counter values, but that does not support implicit
conversion to integral types.
This adds the necessary casts to make the conversions explicit.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (philox_engine::_M_transition): Cast
intermediate values to result_type for n=2 case.
The following patch attempts to implement LWG4483. As written in the
approved resolution, some checks are done on strip_array_types (valuet)
rather than on valuet and one is skipped. Tomasz on IRC reasoned why
input_range should otherwise already ensure we see similar type, so just
for the possibility of fuzzed <meta> the patch adds some verification.
And as the array cases are contiguous, instead of actually recursing (for
which we'd need to have lvalue of the *it rather than prvalue) it just
walks the CONSTRUCTORs for the arrays and handles the elts in there
recursively.
The <meta> changes do exactly what the LWG4483 change says to do.
2026-04-15 Jakub Jelinek <jakub@redhat.com>
* reflect.cc (adjust_array_elt): New function.
(get_range_elts): Implement LWG4483 - Multidimensional arrays are not
supported by meta::reflect_constant_array and related functions.
Handle ARRAY_TYPE valuet. Don't unshare_expr in the class valuet case,
get_template_param_object will unshare.
* g++.dg/reflect/reflect_constant_array9.C: New test.
* g++.dg/reflect/reflect_constant_array10.C: New test.
* g++.dg/reflect/reflect_constant_array11.C: New test.
* g++.dg/reflect/define_static_array6.C: New test.
* g++.dg/reflect/define_static_object2.C: Uncomment older tests and
fix them, add tests for unions.
* include/std/meta (define_static_object): Adjust for LWG4483 changes
- handle unions and arrays differently.
Reviewed-by: Jason Merrill <jason@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
This implements LWG4550: Need new feature test macros for <stdckdint.h>
and <stdbit.h>.
libstdc++-v3/ChangeLog:
* include/bits/version.def (stdbit_h, stdckdint_h): Define.
* include/bits/version.h: Regenerate.
* include/c_compatibility/stdbit.h (__cpp_lib_stdbit_h): Define
and use it in guards.
* include/c_compatibility/stdckdint.h (__cpp_lib_stdckdint_h):
Define and use it in guards.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This implements P3978R3: constant_wrapper should unwrap on call and subscript.
The operator() and operator[] are now fallback to calling corresponding
operation on value, if either arguments are not constant_wrapper like, or
the result of the invocation is not usable as non-type template argument
(non-constant). The call operator is also now defined in terms of invoke,
to support member pointers.
The noexcept specification is simplified, by observing that creating a
default constructed (constant_wrapper<value(....)>{}) is never throwing
operation. Nested requires expr is used for short-circuting, and thus
avoid checking viability of the operation on the value with
constant_wrapper only (see PoisonedAdd, PoisonedIndex in tests).
libstdc++-v3/ChangeLog:
* include/bits/version.def (constant_wrapped): Updated to 202603L.
* include/bits/version.h: Regenerate.
* include/bits/utility.h (_CwOperators::operator())
(_CwOperators:operator[]): Delete, they are now provided by...
(constant_wrapper::operator(), constant_wrapper::operator[]):
Define.
* testsuite/20_util/constant_wrapper/generic.cc: Add additional
test cases for invoke and subscript.
* testsuite/20_util/constant_wrapper/version.cc: Update tested
value.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
There is no need to use std::__addressof in post-C++11 code.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h: Replace usages of std::__addressof with
std::addressof.
* include/bits/hashtable_policy.h: Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
This implements P3886R0: Wording for AT1-057, by defining the
__cpp_lib_replaceable_contract_violation_handler. The macro is defined
only if contracts are supported (i.e. under same conditions as
__cpp_lib_contracts).
GCC supports providing custom violation handler by providing an separate
defintion of handle_contract_violation. This is supported on the targets
that uses ELF format, so the macro is defined for with non-zero value
for them.
libstdc++-v3/ChangeLog:
* include/bits/version.def (replaceable_contract_violation_handler)
[(__cplusplus > 202302L) && (__cpp_contracts >= 202502L)]:
Define to 202603 for ELF targets, and 0 otherwise.
* include/bits/version.h: Regenerate.
* include/std/contracts: Define
__cpp_lib_replaceable_contract_violation_handler.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
SG-10 agreed on using 202604L value for paper P3961R0 that
also updates __cpp_lib_function_ref macro.
libstdc++-v3/ChangeLog:
* include/bits/version.def (function_ref): Bump to 202603L.
* include/bits/version.h: Regenerate.
* testsuite/20_util/function_ref/assign.cc: Remove repeated
check for feature test macro.
* testsuite/20_util/function_ref/cons.cc: Updated checked
value.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This patch implements P3828R1: Rename the to_input view to as_input.
The paper suggest renaming the feature test macro without changing the
value and this patch follows.
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges_to_input): Rename to...
(ranges_as_input): Rename from ranges_as_input.
* include/bits/version.h: Regenerate.
* include/std/ranges (ranges::to_input_view, views::to_input)
(__detail::__can_to_input, views::_ToInput): Rename to...
(ranges::as_input_view, views::as_input, __detail::__can_as_input)
(views::_AsInput): Rename from above...
* src/c++23/std.cc.in: Rename views::to_input and to_input_view
export.
* testsuite/25_algorithms/contains/1.cc: Replace views::to_input
with views::as_input.
* testsuite/std/ranges/adaptors/to_input/1.cc: Move to...
* testsuite/std/ranges/adaptors/as_input/1.cc: ...here, and replace
views::to_input with views::as_input.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/range_args.C: Replace views::to_input with
views::as_input.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This implements P3217R0 and adds default argument for the value type
templater parameter for uninitialized_fill, uninitialized_fill_n and
their ranges counterpart.
libstdc++-v3/ChangeLog:
* include/bits/ranges_uninitialized.h
(__uninitialized_fill_fn::operator())
(__uninitialized_fill_fn_n::operator()): Add default argument
for _Tp parameter.
* include/bits/stl_uninitialized.h (std::unitialized_fill)
(std::unitialized_fill_n): Likewise.
* include/pstl/glue_memory_defs.h (std::unitialized_fill)
(std::unitialized_fill_n): Likewise.
* include/bits/version.def (algorithm_default_value_type):
Bump to 202603.
* include/bits/version.h: Regenerate.
* testsuite/25_algorithms/default_template_value.cc:
Test for new algorithms.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
