Now that we don't use the EBO we can flatten the _Sp_counted_deleter and
_Sp_counted_ptr_inplace layouts by removing their _Impl classes.
libstdc++-v3/ChangeLog:
* include/bits/out_ptr.h (out_ptr_t::_Impl::~_Impl): Adjust
access to shared_ptr internals.
* include/bits/shared_ptr_base.h (_Sp_counted_deleter): Remove
_Impl class and replace _M_impl with the data members it
contained.
(_Sp_counted_ptr_inplace): Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Clang 9 added support for [[__no_unique_address__]] and we don't support
Intel icc any longer, so we can remove the code in <tuple> that works
around the absence of that attribute. We can also address a FIXME in
<bits/shared_ptr_base.h> and replace uses of EBO with the attribute.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h (_Sp_ebo_helper): Simplify by
using [[__no_unique_address__]] instead of EBO. Use the
attribute unconditionally for the unstable ABI.
(_Sp_counted_deleter::_Impl): Adjust uses of _Sp_ebo_helper.
(_Sp_counted_ptr_inplace::_Impl): Likewise.
* include/std/tuple (_Head_base): Remove implementation for
compilers that don't support [[__no_unique_address__]]. Use the
attribute unconditionally for the unstable ABI.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
We convert all contiguous ranges into span of the possibly-const qualified
_Tp (__format::__maybe_const<_Tp, _CharT>). The span object is const qualifed,
to trigger _M_format<const span<T>> specialization, that is already used by
formatter specialization for ranges.
This conversion is applied regardless if range is sized, and ranges::distance
to compute the size. Even for user-defined iterators, they will observe range
being iterated only once.
Finally, using raw pointers to iterate range during formatting guarantees,
that no stdio lock will be taken. In consequence it would be now possible
to enable_nonlocking_formatter_optimization for all contiguous ranges.
libstdc++-v3/ChangeLog:
* include/std/format (range_formatter::format): Format all
contiguous ranges as span<__format::__maybe_const<_Tp, _CharT>>.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Clang 10 added support for concepts, so we no longer need to support
C++20 compilers that don't define __cpp_concepts.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr.h (_UnboundedArray, _BoundedArray)
(_NotUnboundedArray): Remove fallback definition for C++20
compilers that don't define __cpp_concepts.
* include/bits/shared_ptr_base.h (_Sp_counted_ptr_inplace):
Remove fallback declaration of _Sp_overwrite_tag partial
specialization.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
This implements the P3961R1: Less double indirection in function_ref.
This patch uses provision provided by the paper for implementations, and
expands the set of the compatible signatures to include ParamType&& and
ParamType, and by value return types that differs only in cv-qualifiers.
This follows the move_only_function approach from the r16-617-g708d40ff109c6e.
Futhermore the optimization is also applied when function_ref<Ret(Args...) const>
is constructed from function_ref<Ret(Args...)>, even if the underyling target
is be mutated by the call.
The implementations moves the _M_ptrs members to newly defined base class
__polyfunc::_Ref_base. This allows us to reuse existing __base_of and
__invoker_of accessor in the implementation (after befriending them).
The accessors functions are also now marked as constexpr. Furthermore,
_Ref_base default constructor initializes the _M_ptrs._M_obj to nullptr,
and _M_init function is transfered to it, making it instantiations
independent from callback signature.
To check signature compatiblity required by standard for assignment, new
__is_funcref_assignable function is used, and _ArgsSignature and _TargetQuals
member typedef are defined in function_ref. To avoid confusion between adjusted
and specified signature, _Signature typedef is removed from all wrappers, and
__is_invoker_convertible is updated to use _Invoker::_Signature instead.
Per SG-10 guidance __cpp_lib_function_ref feature test macro is updated to
202604, differntiating from P3948R1 paper accepted at the same time.
PR libstdc++/119126
libstdc++-v3/ChangeLog:
* include/bits/funcwrap.h : (__polyfunc::__invoker_of):
Updated to use _Invoker::_Signature and mark as constexpr.
(__polyfunc::_base_of): Mark as constexpr.
(__std:::__is_function_ref_v, __polyfunc::_Ref_base)
(__polyfunc::__is_funcref_assignable): Define.
* include/bits/funcref_impl.h (std::function_ref): Add base class
of type__polyfunc::_Ref_base. Befriend __invoker_of, __base_of,
__is_invoker_convertible, __is_invoker_convertible.
(function_ref::_Base): Define.
(function_ref::_M_init, function_ref::_M_ptrs): Move to base class.
(function_ref::function_ref(_Fn&&), function_ref::operator=): Handle
specializations of function_ref with compatible signatures.
(function_ref::function_ref): Init base class before _M_invoke
consistently, and remove setting of _M_nullptr.
* include/bits/cpyfunc_impl.h (copyable_function): Udpdated friend
declarations.
(copyable_function::_Signature): Remove.
* include/bits/mofunc_impl.h (move_only_function): Udpdated friend
declarations.
(move_only_function::_Signature): Remove.
* include/bits/version.def (function_ref): Bump to 202604.
* include/bits/version.h: Regnerate.
* testsuite/20_util/function_ref/cons.cc: Updated checked FTM value.
* testsuite/20_util/function_ref/conv.cc: Updated test to illustrate
that double indirection is avoided.
* testsuite/20_util/function_ref/dangling.cc: Test for initializing
from function_ref with compatible signature.
* testsuite/20_util/function_ref/dangling_neg.cc: Test for
initializing from function_ref with incompatible signature.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This code was moved from a header into the library, so is no longer
affected by compiler options used when including the headers. We can
just use std::hardware_destructive_interference_size now, and remove the
comment.
libstdc++-v3/ChangeLog:
* src/c++20/atomic.cc (__waitable_state::_S_align): Remove.
(__waitable_state::_M_waiters, __waitable_state::_M_ver): Use
std::hardware_destructive_interference_size for alignment.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Doxygen renamed the "Modules" documentation to "Topics" a few years ago
to avoid confusion with C++20 Modules:
https://github.com/doxygen/doxygen/issues/8772
This updates our internal link to 'modules.html' so that it refers to
'topics.html' instead.
libstdc++-v3/ChangeLog:
PR libstdc++/109965
* doc/doxygen/mainpage.html: Link to topics.html instead of
modules.html
This implements LWG 4324, "unique_ptr<void>::operator* is not
SFINAE-friendly", approved in Croydon, 2026.
The noexcept-specifier added to C++23 by LWG 2762 is ill-formed if the
pointer type cannot be dereferenced, which means that code which was
checking whether the function exists (e.g. in a SFINAE context) no
longer works. Such code was always questionable, because the function
body was ill-formed if the pointer isn't dereferenceable, so the SFINAE
check was probably giving the wrong answer, but it was possible to ask
the question. Since LWG 2762 just asking the question can produce an
error outside the immediate context, so operator* is no longer
SFINAE-friendly.
LWG 4324 adds a constraint to the function, so that it doesn't
participate in overload resolution if it would be ill-formed. That's
easy to implement for C++20 because we can just add a requires-clause.
For C++11/14/17 we can't constrain it easily, so just adjust the
noexcept-specifier so that it's not ill-formed. This still means you get
the wrong answer (i.e. it looks like unique_ptr<void>::operator* is
callable) but there's no error outside the immediate context. This
restores the original semantics before the LWG 2762 change, for better
or worse.
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (unique_ptr::_Nothrow_deref): New
helper for pre-C++20.
(unique_ptr::operator*): Either constrain or use _Nothrow_deref.
* testsuite/20_util/unique_ptr/lwg4324.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Replace it with std::__is_constant_wrapper_v from utility.
libstdc++-v3/ChangeLog:
* include/std/mdspan: Replace eight spaces with tabs.
(__mdspan::__is_constant_wrapper): Remove.
(__mdspan::__acceptable_slice_type, __mdspan::__static_slice_extent)
(__mdspan::__is_unit_stride_slice, __mdspan::__canonical_range_slice)
(__mdspan::__check_inrange_index, __mdspan::__check_valid_index)
(__mdspan::__check_valid_slice): Use std::__is_constant_wrapper_v.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
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>
