It meets Cpp17RandomAccessIterator requirements, but does not satisfy
random_access_iterator concept.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_iterators.h: Modify comment.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This patch replaces uses of subscripts in heap algorithms, that where introduced
in r16-4100-gaaeca77a79a9a8 with dereference of advanced iterators.
The Cpp17RandomAccessIterator requirements, allows operator[] to return any
type that is convertible to reference, however user-provided comparators are
required only to accept result of dereferencing the iterator (i.e. reference
directly). This is visible, when comparator defines operator() for which
template arguments can be deduduced from reference (which will fail on proxy)
or that accepts types convertible from reference (see included tests).
For test we introduce a new proxy_random_access_iterator_wrapper iterator
in testsuite_iterators.h, that returns a proxy type from subscript operator.
This is separate type (instead of additional template argument and aliases),
as it used for test that work with C++98.
libstdc++-v3/ChangeLog:
* include/bits/stl_heap.h (std::__is_heap_until, std::__push_heap)
(std::__adjust_heap): Replace subscript with dereference of
advanced iterator.
* testsuite/util/testsuite_iterators.h (__gnu_test::subscript_proxy)
(__gnu_test::proxy_random_access_iterator_wrapper): Define.
* testsuite/25_algorithms/sort_heap/check_proxy_brackets.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
On Sat, Jan 10, 2026 at 05:24:15PM +0100, Stefan Schulze Frielinghaus wrote:
> libstdc++-v3/ChangeLog:
>
> * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Add
> names {,P,K}DF16.
This is wrong - an ABI issue.
You can't export new symbols in CXXABI_1.3.14 symbol version when they
weren't exported there in GCC 13.1 already.
Symbols new in GCC 16 like these should be exported in CXXABI_1.3.17.
Fixed thusly.
2026-01-12 Jakub Jelinek <jakub@redhat.com>
* config/abi/pre/gnu.ver (CXXABI_1.3.14): Don't export _ZTI*DF16_ on
s390x.
(CXXABI_1.3.17): Export _ZTI*DF16_ on s390x.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Remove
_ZTI{,P,K}DF16_.
This updates test01, so it properly handle 128bit floating points,
including situation when long double uses such representation.
Firstly, the computation of skips is corrected, by discarding number
values equal to number of calls required to generate element
(skips become zero for all non-float correctly). Furthermore, checks
of histogram for types using iec559 representation, is moved inside
test01 function, so we use correct value for long double, depending
on number of digits in mantissa on given platform.
We also extend test to cover __float128, to test 128bit floating
point on more platforms.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Updated test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This patch adds support for _Float16. As time of writing this, there is
no hardware _Float16 support on s390. Therefore, _Float16 operations
have to be extended and truncated which is supported via soft-fp.
The ABI demands that _Float16 values are left aligned in FP registers
similar as it is already the case for 32-bit FP values. If vector
extensions are available, copying between left-aligned FPRs and
right-aligned GPRs is natively supported. Without vector extensions,
the alignment has to be taken care of manually. For target z10,
instructions lgdr/ldgr can be used in conjunction with shifts. Copying
via lgdr from an FPR into a GPR is the easy case since for the shift the
target GPR can be utilized. However, copying via ldgr from a GPR into a
FPR requires a secondary reload register which is used for the shift
result and is then copied into the FPR. Prior z10, there is no hardware
support in order to copy directly between FPRs and GPRs. Therefore, in
order to copy from a GPR into an FPR we would require a secondary reload
register for the shift and secondary memory for copying the aligned
value. Since this is not supported, _Float16 support starts with z10.
As a consequence, for all targets older than z10 test
libstdc++-abi/abi_check fails.
gcc/ChangeLog:
* config/s390/s390-modes.def (FLOAT_MODE): Add HF mode.
(VECTOR_MODE): Add V{1,2,4,8,16}HF modes.
* config/s390/s390.cc (s390_scalar_mode_supported_p): For 64-bit
targets z10 and newer support HF mode.
(s390_vector_mode_supported_p): Add HF mode.
(s390_register_move_cost): Keep HF mode operands in registers.
(s390_legitimate_constant_p): Support zero constant.
(s390_secondary_reload): For GPR to FPR moves a secondary reload
register is required.
(s390_secondary_memory_needed): GPR<->FPR moves don't require
secondary memory.
(s390_libgcc_floating_mode_supported_p): For 64-bit targets z10
and newer support HF mode.
(s390_hard_regno_mode_ok): Allow HF mode for FPRs and VRs.
(s390_function_arg_float): Consider HF mode, too.
(s390_excess_precision): For EXCESS_PRECISION_TYPE_FLOAT16
return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16.
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Define.
* config/s390/s390.md (movhf): Define.
(reload_half_gprtofpr_z10): Define.
(signbithf2): Define.
* config/s390/vector.md: Add new vector modes to various
iterators.
libgcc/ChangeLog:
* config.host: Include s390/t-float16.
* config/s390/libgcc-glibc.ver: Export symbols
__trunc{sf,df,tf}hf2, __extendhf{sf,df,tf}2, __fix{,uns}hfti,
__float{,un}tihf, __floatbitinthf.
* config/s390/t-softfp: Add to softfp_extras instead of setting
it.
* configure: Regenerate.
* configure.ac: Support float16 only for 64-bit targets z10 and
newer.
* config/s390/_dpd_dd_to_hf.c: New file.
* config/s390/_dpd_hf_to_dd.c: New file.
* config/s390/_dpd_hf_to_sd.c: New file.
* config/s390/_dpd_hf_to_td.c: New file.
* config/s390/_dpd_sd_to_hf.c: New file.
* config/s390/_dpd_td_to_hf.c: New file.
* config/s390/t-float16: New file.
libstdc++-v3/ChangeLog:
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Add
names {,P,K}DF16.
gcc/testsuite/ChangeLog:
* g++.target/s390/float16-1.C: New test.
* g++.target/s390/float16-2.C: New test.
* gcc.target/s390/float16-1-2.h: New test.
* gcc.target/s390/float16-1.c: New test.
* gcc.target/s390/float16-10.c: New test.
* gcc.target/s390/float16-2.c: New test.
* gcc.target/s390/float16-3.c: New test.
* gcc.target/s390/float16-4.c: New test.
* gcc.target/s390/float16-5.c: New test.
* gcc.target/s390/float16-6.c: New test.
* gcc.target/s390/float16-7.c: New test.
* gcc.target/s390/float16-8.c: New test.
* gcc.target/s390/float16-9.c: New test.
* gcc.target/s390/float16-signbit.h: New test.
* gcc.target/s390/vector/vec-extract-4.c: New test.
* gcc.target/s390/vector/vec-float16-1.c: New test.
On the mingw32 target, std::system_category().message(int) uses
FormatMessage api to format error messages. When the error message
contains insert sequences, it is unsafe not to use the
FORMAT_MESSAGE_OGNORE_INSERTS flag, as seen at:
https://devblogs.microsoft.com/oldnewthing/20071128-00/?p=24353
The output of FormatMessage ends with "\r\n" and includes a Full stop
character used by the current thread's UI language. Now, we will remove
"\r\n" and any trailing '.' from the output in any language environment.
In the testsuite for std::system_category().message(int), we first
switch the thread UI language to en-US to meet expectations in any
language environment.
libstdc++-v3/ChangeLog:
* src/c++11/system_error.cc (system_error_category) [_WIN32]:
Use FormatMessageA function instead of FormatMessage macro.
* testsuite/19_diagnostics/error_category/system_category.cc:
Fix typo in __MINGW32__ macro name. Adjust behavior on the
mingw32 target.
The __wait_args::_M_setup_proxy_wait function must only be called when
_M_obj == addr is true, so it's redundant for _M_setup_proxy_wait to
pass addr to use_proxy_wait. That address is already passed as
args._M_old anyway.
libstdc++-v3/ChangeLog:
* src/c++20/atomic.cc (use_proxy_wait): Remove unused second
parameter.
(__wait_args::_M_setup_proxy_wait): Remove second argument.
(__notify_impl): Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
A failed assertion was observed with std::atomic<bool>::wait when the
loop in __atomic_wait_address is entered and calls _M_setup_wait a
second time, after waking from __wait_impl. When the first call to
_M_setup_wait makes a call to _M_setup_proxy_wait that function decides
that a proxy wait is needed for an object of type bool, and it updates
the _M_obj and _M_obj_size members to refer to the futex in the proxy
state, instead of referring to the bool object itself. The next time
_M_setup_wait is called it calls _M_setup_proxy_wait again but now it
sees _M_obj_size == sizeof(futex) and so this time decides a proxy wait
is *not* needed, and then fails the __glibcxx_assert(_M_obj == addr)
check.
The problem is that _M_setup_proxy_wait wasn't correctly handling the
case where it's called a second time, after the decision to use a proxy
wait has already been made. That can be fixed in _M_setup_proxy_wait by
checking if _M_obj != addr, which implies that a proxy wait has already
been set up by a previous call. In that case, _M_setup_proxy_wait should
only update _M_old to the latest value of the proxy _M_ver.
This change means that _M_setup_proxy_wait is safe to call repeatedly
for a proxy wait, and will only update _M_wait_state, _M_obj, and
_M_obj_size on the first call. On the second and subsequent calls, those
variables are already correctly set for the proxy wait so don't need to
be set again.
For non-proxy waits, calling _M_setup_proxy_wait more than once is safe,
but pessimizes performance. The caller shouldn't make a second call to
_M_setup_proxy_wait because we don't need to check again if a proxy wait
should be used (the answer won't change) and we don't need to load a
value from the proxy _M_ver.
However, it was difficult to detect the case of a non-proxy wait,
because _M_setup_wait doesn't know if it's being called the first time
(when _M_setup_proxy_wait is called to make the initial decision) or a
subsequent time (in which case _M_obj == addr implies a non-proxy wait
was already decided on). As a result, _M_setup_proxy_wait was being used
every time to see if it's a proxy wait. We can resolve this by splitting
the _M_setup_wait function into _M_setup_wait and _M_on_wake, where the
former is only called once to do the initial setup and the latter is
called after __wait_impl returns, to prepare to check the predicate and
possibly wait again. The new _M_on_wake function can avoid unnecessary
calls to _M_setup_proxy_wait by checking _M_obj == addr to identify a
non-proxy wait.
The three callers of _M_setup_wait are updated to use _M_on_wake instead
of _M_setup_wait after waking from a waiting function. This change
revealed a latent performance bug in __atomic_wait_address_for which was
not passing __res to _M_setup_wait, so a new value was always loaded
even when __res._M_has_val was true. By splitting _M_on_wake out of
_M_setup_wait this problem became more obvious, because we no longer
have _M_setup_wait doing two different jobs, depending on whether it was
passed the optional third argument or not.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__atomic_wait_address_until):
Use _M_on_wake instead of _M_setup_wait after waking.
(__atomic_wait_address_for): Likewise.
* include/bits/atomic_wait.h (__atomic_wait_address): Likewise.
(__wait_args::_M_setup_wait): Remove third parameter and move
code to update _M_old to ...
(__wait_args::_M_on_wake): New member function to update _M_old
after waking, only calling _M_setup_proxy_wait if needed.
(__wait_args::_M_store): New member function to update _M_old
from a value, for non-proxy waits.
* src/c++20/atomic.cc (__wait_args::_M_setup_proxy_wait): If
_M_obj is not addr, only load a new value and return true.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
As noted in Bug 122878 comment 2, the _M_try_acquire_for implementation
doesn't reduce the remaining timeout each time it returns from an atomic
waiting function. This means that it can wait longer than requested, or
even loop forever. If there is a spurious wake from the timed waiting
function (__wait_until_impl) it will return indicating no timeout
occurred, which means the caller will check the value and potentially
sleep again. If spurious wakes happen every time, it will just keep
sleeping in a loop forever. This is observed to actually happen on
FreeBSD 14.0-STABLE where pthread_cond_timedwait gets a spurious wake
and so never times out.
The solution in this commit is to replace the implementation of
_M_try_acquire_for with a call to _M_try_acquire_until, converting the
relative timeout to an absolute timeout against the steady clock. This
is what ends up happening anyway, because we only have a
__wait_until_impl entry point into the library internals, so
__atomic_wait_address_for already converts the relative timeout to an
absolute timeout (except for the special case of a zero-value duration,
which only checks for an update while spinning for a finite number of
iterations, and doesn't sleep).
As noted in comment 4 of the PR, this requires some changes to
_M_try_acquire which was relying on the behaviour of _M_try_acquire_for
for zero-value durations. That behaviour is desirable for
_M_try_acquire so that it can handle short-lived contention without
failing immediately. To preserve that behaviour of _M_try_acquire it is
changed to do its own loop and to call __atomic_wait_address_for
directly with a zero duration, to do the spinloop.
libstdc++-v3/ChangeLog:
PR libstdc++/122878
* include/bits/semaphore_base.h (_M_try_acquire): Replace
_M_try_acquire_for call with explicit loop and call to
__atomic_wait_address_for.
(_M_try_acquire_for): Replace loop with call to
_M_try_acquire_until.
Co-authored-by: Tomasz Kamiński <tkaminsk@redhat.com>
Existing toolchain builds rely on the similarity between picolibc and
newlib when building libstdc++ and use --with-newlib.
Switch to the picolibc 16-bit _ctype_wide array which provides
separate values for ctype_base::blank and ctype_base::space.
This fixes a bug where libstdc++ was including '\f', '\n', '\r' and
'\v' in the set of 'blank' chars. Afterwards, only ' ' and '\t' are in
this set, as specified by C++ 11.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CONFIGURE): Add --with-picolibc.
* configure: Regenerate.
* configure.ac: Add handling for with_picolibc=yes.
* config/os/picolibc/ctype_base.h: New file.
* config/os/picolibc/ctype_configure_char.cc: New file.
* config/os/picolibc/ctype_inline.h: New file.
* config/os/picolibc/os_defines.h: New file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Use of scan-assembler-dem for matching against debug symbols, turned out to not
be portable, as they representation in assembly output differs between platforms:
arm use 60 columns limit, emitting multiple rows, and some platforms may encode
them using base64.
We use tree-dump-gimple instead, that outputs a constructor name portably,
allowing us to simply match for invocation of constructor for given type, as each
variable has different type.
To use scan-tree-dump(-not) we load scantree.exp file and it's dependency
scandump.exp from gcc/testsuite/lib.
libstdc++-v3/ChangeLog:
* testsuite/20_util/variant/constinit.cc: Use scan-tree-dump
for matching of constructor.
* testsuite/20_util/variant/constinit_compat.cc: Likewise.
* testsuite/lib/libstdc++.exp: Load scantree.exp and scandump.exp.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
When basic_stringbuf::setbuf has been called we need to copy the
contents of the buffer into _M_string first, before returning that.
libstdc++-v3/ChangeLog:
PR libstdc++/123100
* include/std/sstream (basic_stringbuf::str()&&): Handle the
case where _M_string is not being used for the buffer.
* testsuite/27_io/basic_stringbuf/str/char/123100.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub's fix for PR c++/91388 means that we don't need an unreachable
return statement after static_assert(false).
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__wait_args::_M_setup_wait):
Remove unreachable return statement.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
As explained in the PR, flockfile and funlockfile are always declared by
newlib and there's no easy way to detect whether they're actually
defined. Ensure that ac_stdio_locking=no gets set for non-cygwin newlib
targets.
libstdc++-v3/ChangeLog:
PR libstdc++/123406
* acinclude.m4 (GLIBCXX_CHECK_STDIO_LOCKING): Override detection
of flockfile for non-cygwin newlib targets.
* configure: Regenerate.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
When I replaced the std::unique_ptr member in r16-997-gef632273a90657 I
should have added an explicit delete[] operation to replace the effects
of the unique_ptr destructor.
libstdc++-v3/ChangeLog:
PR libstdc++/123378
* include/std/barrier (~__tree_barrier_base): Define.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
As mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/704712.html
in the gnu::constexpr_only thread, gnu::gnu_inline attribute actually
seems to work for most of what we need for C++26 constexpr exceptions
(i.e. when we want out of line bodies for C++ < 26 and need to use
constexpr for C++26, yet don't want for reasons mentioned in those
two PRs the bodies of those constexpr methods to be emitted inline).
Unfortunately clang++ doesn't handle it 100% properly and requires
the redundant inline keyword to make it work (even when the methods
are constexpr and thus implicilty inline), g++ doesn't require that,
so the patch adds also the redundant inline keywords and not just
the [[__gnu__::__gnu_inline__]] attribute.
This way if something wants to inline those functions it can, but
if their address is taken, we just rely on libstdc++.{so,a} to provide
those (which it does as before because those TUs are compiled with
older -std= modes).
The earlier r16-6477-gd5743234731 commit made sure gnu::gnu_inline
constexpr virtual methods can be key methods, so vtables and rtti can
be emitted only in the TU defining non-gnu_inline versions of those.
2026-01-07 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/123183
PR libstdc++/123326
* libsupc++/exception (std::bad_exception::~bad_exception(),
std::bad_exception::what()): Add inline keyword and
[[__gnu__::__gnu_inline__]] attribute to the C++26 constexpr
exceptions definitions.
* libsupc++/exception.h (std::exception::~exception(),
std::exception::what()): Likewise.
* libsupc++/exception_ptr.h (std::exception_ptr::exception_ptr(void*)):
Likewise.
* libsupc++/nested_exception.h
(std::nested_exception::~nested_exception()): Likewise.
* libsupc++/typeinfo (std::bad_cast::~bad_cast(),
std::bad_cast::what(), std::bad_typeid::~bad_typeid(),
std::bad_typeid::what()): Likewise.
* include/bits/new_except.h (std::bad_alloc::~bad_alloc(),
std::bad_alloc::what(),
std::bad_array_new_length::~bad_array_new_length(),
std::bad_array_new_length::what()): Likewise.
* include/bits/stdexcept_except.h
(std::logic_error::logic_error(const string&),
std::logic_error::logic_error(const char*),
std::logic_error::~logic_error(), std::logic_error::what(),
std::domain_error::domain_error(const string&),
std::domain_error::domain_error(const char*),
std::invalid_argument::invalid_argument(const string&),
std::invalid_argument::invalid_argument(const char*),
std::length_error::length_error(const string&),
std::length_error::length_error(const char*),
std::out_of_range::out_of_range(const string&),
std::out_of_range::out_of_range(const char*),
std::runtime_error::runtime_error(const string&),
std::runtime_error::runtime_error(const char*),
std::runtime_error::~runtime_error(), std::runtime_error::what(),
std::overflow_error::overflow_error(const string&),
std::overflow_error::overflow_error(const char*),
std::overflow_error::~overflow_error(),
std::underflow_error::underflow_error(const string&),
std::underflow_error::underflow_error(const char*),
std::underflow_error::~underflow_error()): Likewise.
(std::domain_error::~domain_error(),
std::invalid_argument::~invalid_argument(),
std::length_error::~length_error(),
std::out_of_range::~out_of_range()): Likewise. Also change
_GLIBCXX_NOTHROW to noexcept on those definitions.
GNU ld gained separate Solaris-specific linker emulations (*_sol2) long
ago. Since their introduction, GCC has preferred them over their
non-*_sol2 counterparts but supported both forms. This has changed for
GCC 16: since all supported versions of GNU ld do support the *_sol2
emulations, GCC now uses them unconditionally.
libtool has also been updated to handle this since libtool 2.4.2 back in
2011. However, that change has only partially been backported to the
heavily patched libtool.m4 in the GCC tree: the sparcv9 part is there,
but the amd64 part is missing for some reason. This causes problems
with some recent binutils changes.
Therefore this patch cherry-picks the libtool patch to bring
Solaris/x86_64 in sync with Solaris/sparcv9 and upstream libtool.
Bootstrapped without regressions on {amd64,i386}-pc-solaris2.11 and
{sparcv9,sparc}-sun-solaris2.11.
2025-09-22 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* libtool.m4: Cherry-pick libtool commit
9196966580f6853a31187a7a3c7e7ff36ef08982.
gcc:
* configure: Regenerate.
libatomic:
* configure: Regenerate.
libbacktrace:
* configure: Regenerate.
libcc1:
* configure: Regenerate.
libffi:
* configure: Regenerate.
libga68:
* configure: Regenerate.
libgcobol:
* configure: Regenerate.
libgfortran:
* configure: Regenerate.
libgm2:
* configure: Regenerate.
libgomp:
* configure: Regenerate.
libgrust:
* configure: Regenerate.
libitm:
* configure: Regenerate.
libobjc:
* configure: Regenerate.
libphobos:
* configure: Regenerate.
libquadmath:
* configure: Regenerate.
libsanitizer:
* configure: Regenerate.
libssp:
* configure: Regenerate.
libstdc++-v3:
* configure: Regenerate.
libvtv:
* configure: Regenerate.
lto-plugin:
* configure: Regenerate.
zlib:
* configure: Regenerate.
The _GLIBCXX_USE_OLD_GENERATE_CANONICAL was introduced by
r16-6177-g866bc8a9214b1d that implemented P0952R2 [1] resolution
for LWG2524 as DR against C++20.
The _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI was introduced by
r16-6301-gb3c167b61fd75f that resovled PR112591.
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html
libstdc++-v3/ChangeLog:
* doc/html/manual/using_macros.html: Regenerate.
* doc/xml/manual/using.xml: Add entries for
_GLIBCXX_USE_OLD_GENERATE_CANONICAL and
_GLIBCXX_USE_VARIANT_CXX17_OLD_ABI.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This patch disables use of specialization _Uninitialized<_Type, false> for
non-trivially destructible types by default in C++17, and fallbacks to
the primary template, that stores the type in union directly. This makes the
ABI consistent between C++17 and C++20 (or later). This partial specialization
is no longer required after the changes introduced in r16-5961-g09bece00d0ec98.
This fixes non-conformance in C++17 mode where global variables of a variant
specialization type, were not statically-initialized for non-trivially
destructible types, even if initialization of the selected alternative could
be performed at compile time. For illustration, the following global variable
will be statically initialized after this change:
std::variant<std::unique_ptr<T>, std::unique_ptr<U>> ptr;
This constitutes an ABI break, and changes the layout of the types, that uses
the same non-trivially copyable both as the base class, as alternative of the
variant object that is first member:
struct EmptyNonTrivial { ~EmptyNonTrivial(); };
struct Affected : EmptyNonTrivial {
std::variant<EmptyNonTrivial, char> mem; // mem was at offset zero,
// will use non-zero offset now
};
After changes the layout of such types consistent with one used for empty types
with trivial destructor, or one used for any empty type in C++20 or later.
For programs affected by this change, it can be reverted in C++17 mode, by
defining _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI. However, presence of this macro
has no effect in C++20 or later modes.
PR libstdc++/112591
libstdc++-v3/ChangeLog:
* include/std/variant (_Uninitialized::_M_get, __get_n)
(_Uninitialized<_Type, false>): Add _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI
check to preprocessor guard.
* testsuite/20_util/variant/112591.cc: Updated tests.
* testsuite/20_util/variant/112591_compat.cc: New test.
* testsuite/20_util/variant/constinit.cc: New test.
* testsuite/20_util/variant/constinit_compat.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Accidentally dropped from commit.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon_eng.cc:
Test __float128 when available.
If the span of the range R produced by uniform bit generator U passed to
generate_canonical is not power of two, we need to use algorithm that
requires computing power R^k that is greater than 2^d, where d is number
of digits in mantissa of _RealT. Previously we have used an integer type
that is has twice as many digits as d. This lead to situation that for
standard engines that produced such range (like std::minstd_rand0,
std::minstd_rand, std::ranlux24, ....) 256bit integer support was
required for 128bit floats. However, in this cases R^4 provides more
than d bits of precision, while requiring 124 bits.
We overestimate the number of required bits, by computing a value
l * bit_width(R) (log2(R) + 1), where l is value such that log2(R) * l >= d.
As R >= 2^log2(R), then R^l >= (2^log2(R))^l == 2^(log(R) * l) >= 2^d,
so k+1 >= l >= k. In consequence R^k is smaller R^l which require at most
l * bit_width(R). This is an overestimate, but difference should not be
higher than l bits.
We replace __gen_can_pow and __gen_can_rng_calls_needed with
__gen_canon_log(v, b), which computes the largest power of b that fits into v.
As such a number is smaller than v, the result will always fit in it's type.
Both the logarithm and the power value are returned using
__gen_canon_log_res struct.
libstdc++-v3/ChangeLog:
* include/bits/random.h (__rand_uint128::operator>)
(__rand_uint128::operator>=): Define.
* include/bits/random.tcc (__generate_canonical_pow2):
Adjust for use of __rand_uint128 in C++11.
(__gen_can_pow, __gen_can_rng_calls_needed): Replace with
__gen_canon_log.
(__gen_canon_log_res, __gen_canon_log): Define.
(__generate_canonical_any): Reworked how _UInt is determined.
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon_eng.cc:
New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
When we extract wide characters and insert them into a stringstream to
be parsed as a floating-point value, we should use a stringstream of
char, not wchar_t.
libstdc++-v3/ChangeLog:
PR libstdc++/123147
* include/bits/chrono_io.h (_Parser::operator()) <%S>: Use a
buffer of narrow characters to be parsed by std::from_chars.
* testsuite/std/time/parse/parse.cc: Check wchar_t parsing.
This functions are indirectly called from flat_ containers operations
(from preconditions check of lower_bound, upper_bound, ...) that were
made constexpr by r16-6026-gbf9dd44a97400e, leading to test with
in _GLIBCXX_DEBUG mode.
For __can_advance we uncoditionally return true in constant evaluation,
similary to __valid_range. The constexpr iterator will detect comparision
of iterator to different ranges.
libstdc++-v3/ChangeLog:
* include/debug/helper_functions.h (__gnu_debug::__can_advance):
Declare as _GLIBCXX20_CONSTEXPR.
* include/debug/safe_iterator.h (__gnu_debug::__can_advance):
Define as _GLIBCXX20_CONSTEXPR, and return true for constexpr
evaluation.
(__gnu_debug::__base): Define as _GLIBCXX20_CONSTEXPR.
Adjust the return type to be consistent with how it's declared in
<mutex>.
libstdc++-v3/ChangeLog:
* src/c++11/mutex.cc [_GLIBCXX_NO_EXTERN_THREAD_LOCAL]
(__get_once_call): Use std::add_lvalue_reference.
For Windows, GCC can be configured with `--enable-tls` to enable native TLS.
The native TLS implementation has a limitation that it is incapable of
exporting thread-local variables from DLLs. Therefore, they are retrieved
via getter functions instead.
libstdc++-v3/ChangeLog:
* config/os/mingw32-w64/os_defines.h (_GLIBCXX_NO_EXTERN_THREAD_LOCAL):
New macro.
* include/std/mutex [_GLIBCXX_NO_EXTERN_THREAD_LOCAL]
(__get_once_callable, __get_once_call): Declare new functions.
* src/c++11/mutex.cc [_GLIBCXX_NO_EXTERN_THREAD_LOCAL]
(__get_once_callable, __get_once_call): Define.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
The logic of the null pointer check got reversed when converting the
std::stable_sort code for ranges::stable_sort.
libstdc++-v3/ChangeLog:
PR libstdc++/123180
* include/bits/ranges_algo.h (__stable_sort_fn::operator()): Fix
sense of null check. Replace typedef with alias-declaration.
* testsuite/25_algorithms/stable_sort/123180.cc: New test.
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Make use of __detail::_Select_uint_least_t<d>::type for
std::generate_canonical, so that we choose an appropriately sized
integer based on the number of bits needed, and so we have a 128-bit
integer type even on 32-bit targets (via the new __rand_uint128 class).
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (__generate_canonical_pow2): Adjust
comments. Remove _UInt template parameter and define it in the
body using _Select_uint_least_t<__d>. Remove popcount call for
getting the width of the _UInt type. Cast floating-point
literal to _RealT.
(__generate_canonical_any): Remove _UInt template parameter and
define it in the body using _Select_uint_least_t<__d * 2>. Use
direct-initialization for _UInt variables. Cast floating-point
literal to _RealT.
(generate_canonical): Remove unused typedef. Remove constexpr-if
branches and remove unsigned type from template argument lists.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
Reviewed-by: Nathan Myers <nmyers@redhat.com>
The COW std::string is not constexpr, so the <stdexcept> exception
classes can't be constexpr either when they're defined in terms of the
COW string.
While constexpr exceptions for <typeinfo>, <new>, and <exception>
classes would work, __cpp_constexpr_exceptions >= 202411L implies that
everything including <stdexcept> should work. So when we can't support
it fully, we shouldn't announce it.
libstdc++-v3/ChangeLog:
* include/bits/version.def (constexpr_exceptions): Add
cxx11abi=yes.
* include/bits/version.h: Regenerate.
* testsuite/18_support/exception/version.cc: Require effectiove
target cxx11_abi.
* testsuite/18_support/exception_ptr/exception_ptr_cast.cc: Only
check for constexpr support in cxx11 ABI.
* testsuite/19_diagnostics/headers/stdexcept/version.cc: Require
effective target cxx11_abi.
* testsuite/19_diagnostics/logic_error/constexpr.cc: Likewise.
* testsuite/19_diagnostics/runtime_error/constexpr.cc: Likewise.
* testsuite/20_util/expected/version.cc: Only check for
__cpp_lib_constexpr_exceptions macro for cxx11 ABI.
* testsuite/20_util/optional/version.cc: Likewise.
* testsuite/20_util/variant/version.cc: Likewise.
Reviewed-by: Jakub Jelinek <jakub@redhat.com>
This moves the __detail::_Select_uint_least_t<N>::type class to
namespace scope and extends it with more 128-bit arithmetic operations,
implemented in terms of uint64_t.
Now std::philox_engine can use _Select_uint_least_t<w*2>::type instead
of __uint128_t, so that it works on targets without 128-bit integers.
This also means that targets that do support __uint128_t only use it
when actually necessary, so that we use uint64_t when generating a
32-bit result (e.g. with std::philox4x32).
libstdc++-v3/ChangeLog:
* include/bits/random.h [!__SIZEOF_INT128__] (__rand_uint128):
Refactor and rename _Select_uint_least_t<128>::type to a new
class. Make all members constexpr. Add new member functions for
additional arithmetic and bitwise operations, and comparisons.
(__detail::_Select_uint_least_t<>::type): Define as an alias of
__rand_uint128.
* include/bits/random.tcc (philox_engine::_M_mulhi): Use
_Select_uint_least_t<w*2>::type instead of __uint128_t.
(philox_engine::_M_transition): Likewise.
* include/bits/version.def (philox_engine): Remove extra_cond.
* include/bits/version.h: Regenerate.
* testsuite/26_numerics/random/philox4x32.cc: Remove
dg-require-cpp-feature-test directive.
* testsuite/26_numerics/random/philox4x64.cc: Likewise.
* testsuite/26_numerics/random/philox_engine/cons/copy.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/cons/default.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/cons/seed.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/operators/equal.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/operators/serialize.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/requirements/constants.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/requirements/typedefs.cc:
Likewise.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
On 32-bit x86 the default -fexcess-precision=fast setting used by
-std=gnu++20 results in unpredictable rounding which alters the number
of times that std::generate_canonical produces exactly 1.0f, which
means that the URBG is invoked a different number of times.
To ensure that the behaviour is consistent and the expected number of
calls happens, use -fexcess-precision=standard.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc:
Add -fexcess-precision=standard to options.
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Likewise.
Reviewed-by: Jakub Jelinek <jakub@redhat.com>
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc
[_GLIBCXX_USE_OLD_GENERATE_CANONICAL]: Restore test01. Do not discard an
extra value in test02.
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Skip if _GLIBCXX_USE_OLD_GENERATE_CANONICAL is defined in options.
This ensures that the new definition of std::generate_canonical has a
different mangled name from the old one, so that TUs compiled with GCC
16 will be sure to use the new definition, even if the linker also sees
a symbol instantiated from the old definition. We use the same _V2
inline namespace as used elsewhere (std::_V2::condition_variable,
std::_V2::__rotate, and std::chrono::_V2::system_clock), and use a macro
to add it conditionally so that it's not used for the ABI-unstable
gnu-versioned-namespace configuration.
We can simplify the 26_numerics/random/pr60037-neg.cc test to only use
one dg-error without a line number, so that it matches any of the three
relevant static_assert failures for this test: the one from _Adaptor in
<bits/random.h> and the ones from the new and old definitions of
std::generate_canonical in <bits/random.tcc>. Without this change, the
line number for the dg-error matching the <bits/random.tcc> error
depends on the _GLIBCXX_USE_OLD_GENERATE_CANONICAL macro, which is
awkward to depend on in the test (because DejaGnu sees all dg-error
directives, it doesn't care if they're guarded by #ifdef preprocessor
checks).
libstdc++-v3/ChangeLog:
* include/bits/random.h [!_GLIBCXX_USE_OLD_GENERATE_CANONICAL]
(generate_canonical): Use inline namespace _V2.
* include/bits/random.tcc [!_GLIBCXX_USE_OLD_GENERATE_CANONICAL]
(generate_canonical): Likewise.
* testsuite/26_numerics/random/pr60037-neg.cc: Remove lineno so
that one dg-error matches both diagnostics.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
