Since glibc 2.27 the pthread_self symbol has been defined in libc rather
than libpthread. Because we only call pthread_self through a weak alias
it's possible for statically linked executables to end up without a
definition of pthread_self. This crashes when trying to call an
undefined weak symbol.
We can use the __GLIBC_PREREQ version check to detect the version of
glibc where pthread_self is no longer in libpthread, and call it
directly rather than through the weak reference.
It would be better to check for pthread_self in libc during configure
instead of hardcoding the __GLIBC_PREREQ check. That would be
complicated by the fact that prior to glibc 2.27 libc.a didn't have the
pthread_self symbol, but libc.so.6 did. The configure checks would need
to try to link both statically and dynamically, and the result would
depend on whether the static libc.a happens to be installed during
configure (which could vary between different systems using the same
version of glibc). Doing it properly is left for a future date, as that
will be needed anyway after glibc moves all pthread symbols from
libpthread to libc. When that happens we should revisit the whole
approach of using weak symbols for pthread symbols.
For the purposes of std::this_thread::get_id() we call
pthread_self() directly when using glibc 2.27 or later. Otherwise, if
__gthread_active_p() is true then we know the libpthread symbol is
available so we call that. Otherwise, we are single-threaded and just
use ((__gthread_t)1) as the thread ID.
An undesirable consequence of this change is that code compiled prior to
the change might inline the old definition of this_thread::get_id()
which always returns (__gthread_t)1 in a program that isn't linked to
libpthread. Code compiled after the change will use pthread_self() and
so get a real TID. That could result in the main thread having different
thread::id values in different translation units. This seems acceptable,
as there are not expected to be many uses of thread::id in programs
that aren't linked to libpthread.
An earlier version of this patch also changed __gthread_self() to use
__GLIBC_PREREQ(2, 27) and only use the weak symbol for older glibc. Tha
might still make sense to do, but isn't needed by libstdc++ now.
libstdc++-v3/ChangeLog:
PR libstdc++/95989
* config/os/gnu-linux/os_defines.h (_GLIBCXX_NATIVE_THREAD_ID):
Define new macro to get reliable thread ID.
* include/bits/std_thread.h: (this_thread::get_id): Use new
macro if it's defined.
* testsuite/30_threads/jthread/95989.cc: New test.
* testsuite/30_threads/this_thread/95989.cc: New test.
This makes it possible to use std::thread without including the whole of
<thread>. It also makes this_thread::get_id() and this_thread::yield()
available even when there is no gthreads support (e.g. when GCC is built
with --disable-threads or --enable-threads=single).
In order for the std:🧵:id return type of this_thread::get_id() to
be defined, std:thread itself is defined unconditionally. However the
constructor that creates new threads is not defined for single-threaded
builds. The thread::join() and thread::detach() member functions are
defined inline for single-threaded builds and just throw an exception
(because we know the thread cannot be joinable if the constructor that
creates joinable threads doesn't exit).
The thread::hardware_concurrency() member function is also defined
inline and returns 0 (as suggested by the standard when the value "is
not computable or well-defined").
The main benefit for most targets is that other headers such as <future>
do not need to include the whole of <thread> just to be able to create a
std::thread. That avoids including <stop_token> and std::jthread where
not required. This is another partial fix for PR 92546.
This also means we can use this_thread::get_id() and this_thread::yield()
in <stop_token> instead of using the gthread functions directly. This
removes some preprocessor conditionals, simplifying the code.
libstdc++-v3/ChangeLog:
PR libstdc++/92546
* include/Makefile.am: Add new <bits/std_thread.h> header.
* include/Makefile.in: Regenerate.
* include/std/future: Include new header instead of <thread>.
* include/std/stop_token: Include new header instead of
<bits/gthr.h>.
(stop_token::_S_yield()): Use this_thread::yield().
(_Stop_state_t::_M_requester): Change type to std:🧵:id.
(_Stop_state_t::_M_request_stop()): Use this_thread::get_id().
(_Stop_state_t::_M_remove_callback(_Stop_cb*)): Likewise.
Use __is_single_threaded() to decide whether to synchronize.
* include/std/thread (thread, operator==, this_thread::get_id)
(this_thread::yield): Move to new header.
(operator<=>, operator!=, operator<, operator<=, operator>)
(operator>=, hash<thread::id>, operator<<): Define even when
gthreads not available.
* src/c++11/thread.cc: Include <memory>.
* include/bits/std_thread.h: New file.
(thread, operator==, this_thread::get_id, this_thread::yield):
Define even when gthreads not available.
[!_GLIBCXX_HAS_GTHREADS] (thread::join, thread::detach)
(thread::hardware_concurrency): Define inline.
This applies the proposed resolution of LWG 3500, which corrects the
return type and constraints of this member function to use the right
iterator type. Additionally, a nearby local variable is uglified.
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Iterator::_M_satisfy): Uglify
local variable inner.
(join_view::_Iterator::operator->): Use _Inner_iter instead of
_Outer_iter in the function signature as per LWG 3500.
* testsuite/std/ranges/adaptors/join.cc (test08): Test it.
The <span> header is empty unless Concepts are supported, but <version>
defines the __cpp_lib_span feature test macro unconditionally. It should
be guarded by the same conditions as in <span>.
libstdc++-v3/ChangeLog:
PR libstdc++/97869
* include/precompiled/stdc++.h: Include <coroutine>.
* include/std/version (__cpp_lib_span): Check __cpp_lib_concepts
before defining.
My ranges transcription of the std::search_n implementation for random
access iterators missed a crucial part of the algorithm which the
existing tests didn't exercise. When __remainder is less than __count
at the start of an iteration of the outer while loop, it means we're
continuing a partial match of __count - __remainder elements from the
previous iteration. If at the end of the iteration we don't complete
this partial match, we need to reset __remainder so that it's only
offset by the size of the most recent partial match before starting the
next iteration.
This patch fixes this appropriately, mirroring how it's done in the
corresponding std::search_n implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/97828
* include/bits/ranges_algo.h (__search_n_fn::operator()): Check
random_access_iterator before using the backtracking
implementation. When the backwards scan fails prematurely,
reset __remainder appropriately.
* testsuite/25_algorithms/search_n/97828.cc: New test.
To poll a std::future to see if it's ready you have to call one of the
timed waiting functions. The most obvious way is wait_for(0s) but this
was previously very inefficient because it would turn the relative
timeout to an absolute one by calling system_clock::now(). When the
relative timeout is zero (or less) we're obviously going to get a time
that has already passed, but the overhead of obtaining the current time
can be dozens of microseconds. The alternative is to call wait_until
with an absolute timeout that is in the past. If you know the clock's
epoch is in the past you can use a default constructed time_point.
Alternatively, using some_clock::time_point::min() gives the earliest
time point supported by the clock, which should be safe to assume is in
the past. However, using a futex wait with an absolute timeout before
the UNIX epoch fails and sets errno=EINVAL. The new code using futex
waits with absolute timeouts was not checking for this case, which could
result in hangs (or killing the process if the libray is built with
assertions enabled).
This patch checks for times before the epoch before attempting to wait
on a futex with an absolute timeout, which fixes the hangs or crashes.
It also makes it very fast to poll using an absolute timeout before the
epoch (because we skip the futex syscall).
It also makes future::wait_for avoid waiting at all when the relative
timeout is zero or less, to avoid the unnecessary overhead of getting
the current time. This makes polling with wait_for(0s) take only a few
cycles instead of dozens of milliseconds.
libstdc++-v3/ChangeLog:
* include/std/future (future::wait_for): Do not wait for
durations less than or equal to zero.
* src/c++11/futex.cc (_M_futex_wait_until)
(_M_futex_wait_until_steady): Do not wait for timeouts before
the epoch.
* testsuite/30_threads/future/members/poll.cc: New test.
This changes the __numeric_traits primary template to assume its
argument is an integer type. For the three floating point types that are
supported by __numeric_traits_floating an explicit specialization of
__numeric_traits chooses the right base class.
This improves the failure mode for using __numeric_traits with an
unsupported type. Previously it would use __numeric_traits_floating as
the base class, and give somewhat obscure errors for trying to access
the static data members. Now it will use __numeric_traits_integer which
has a static_assert to check for supported types.
As a side effect of this change there is no need to instantiate
__conditional_type to decide which base class to use.
libstdc++-v3/ChangeLog:
* include/ext/numeric_traits.h (__numeric_traits): Change
primary template to always derive from __numeric_traits_integer.
(__numeric_traits<float>, __numeric_traits<double>)
(__numeric_traits<long double>): Add explicit specializations.
The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representation. This causes an integer overflow in a constant
expression, which is ill-formed.
This problem was already solved by DJ for std::numeric_limits<__int20>
by generalizing the helper macros to use a specified number of bits
instead of assuming sizeof(T) * CHAR_BIT. Then the INT_N_n types can
specify the number of bits using the __GLIBCXX_BITSIZE_INT_N_n macros
that the compiler defines.
I'm using a slightly different approach here. I've replaced the helper
macros entirely, and just expanded the calculations in the initializers
for the static data members. By reordering the data members we can reuse
__is_signed and __digits in the other initializers. This removes the
repetition of expanding __glibcxx_signed(T) and __glibcxx_digits(T)
multiple times in each initializer.
The __is_integer_nonstrict trait now defines a new constant, __width,
which is sizeof(T) * CHAR_BIT by default (defined as an enumerator so
that no storage is needed for a static data member). By specializing
__is_integer_nonstrict for the INT_N types that have padding bits, we
can provide the correct width via the __GLIBCXX_BITSIZE_INT_N_n macros.
libstdc++-v3/ChangeLog:
PR libstdc++/97798
* include/ext/numeric_traits.h (__glibcxx_signed)
(__glibcxx_digits, __glibcxx_min, __glibcxx_max): Remove
macros.
(__is_integer_nonstrict::__width): Define new constant.
(__numeric_traits_integer): Define constants in terms of each
other and __is_integer_nonstrict::__width, rather than the
removed macros.
(_GLIBCXX_INT_N_TRAITS): Macro to define explicit
specializations for non-standard integer types.
Move assigning to a std::jthread that represents a thread of execution
needs to send a stop request and join that running thread. Otherwise the
std::thread data member will terminate in its assignment operator.
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::operator=(jthread&&)): Transfer
any existing state to a temporary that will request a stop and
then join.
* testsuite/30_threads/jthread/jthread.cc: Test move assignment.
This encapsulates the storing and checking of the thread ID into a class
type, so that the macro _GLIBCXX_HAS_GTHREADS is only checked in one
place. The code doing the checks just calls member functions of the new
type, without caring whether that really does any work or not.
libstdc++-v3/ChangeLog:
* include/std/stop_token (_Stop_state_t::_M_requester): Define
new struct with members to store and check the thread ID.
(_Stop_state_t::_M_request_stop()): Use _M_requester._M_set().
(_Stop_state_t::_M_remove_callback(_Stop_cb*)): Use
_M_requester._M_is_current_thread().
This adds the manipulators for use with basic_osyncstream. In order to
detect when an arbitrary basic_ostream<C,T> is the base class of a
basic_syncbuf<C,T,A> object, introduce a new intermediate base class
that stores the data members. The new base class stores a pointer and
two bools, which wastes (sizeof(void*) - 2) bytes of padding. It would
be possible to use the two least significant bits of the pointer for the
two bools, at least for targets where alignof(basic_streambuf) > 2, but
that's left as a possible change for a future date.
Also define basic_syncbuf::overflow to override the virtual function in
the base class, so that single characters can be inserted into the
stream buffer. Previously the default basic_streambuf::overflow
implementation was used, which drops the character on the floor.
libstdc++-v3/ChangeLog:
* include/std/ostream (__syncbuf_base): New class template.
(emit_on_flush, noemit_on_flush, flush_emit): New manipulators.
* include/std/syncstream (basic_syncbuf): Derive from
__syncbuf_base instead of basic_streambuf.
(basic_syncbuf::operator=): Remove self-assignment check.
(basic_syncbuf::swap): Remove self-swap check.
(basic_syncbuf::emit): Do not skip pubsync() call if sequence
is empty.
(basic_syncbuf::sync): Remove no-op pubsync on stringbuf.
(basic_syncbuf::overflow): Define override.
* testsuite/27_io/basic_syncstream/basic_ops/1.cc: Test
basic_osyncstream::put(char_type).
* testsuite/27_io/basic_ostream/emit/1.cc: New test.
This groups all the constructors together, consistent with the synopses
in the C++20 standard.
libstdc++-v3/ChangeLog:
* include/std/sstream (basic_stringbug, basic_istringstream)
(basic_ostringstream, basic_stringstream): Reorder C++20
constructors to be declared next to other constructors.
This adds some more null checks to avoid a relational comparison with a
null pointer, similar to 78198b6021.
libstdc++-v3/ChangeLog:
PR libstdc++/97415
* include/std/sstream (basic_stringbuf::_M_update_egptr)
(basic_stringbuf::__xfer_bufptrs::__xfer_bufptrs): Check for
null before comparing pointers.
libstdc++-v3/ChangeLog:
* include/debug/assertions.h (__glibcxx_requires_non_empty_range):
Remove __builtin_expect.
(__glibcxx_requires_subscript): Likewise.
(__glibcxx_requires_nonempty): Likewise.
* include/debug/formatter.h (__check_singular): Add C++11 constexpr
qualification.
* include/debug/helper_functions.h (__check_singular): Likewise. Skip
check if constant evaluated.
(__valid_range): Do not skip check if constant evaluated.
* include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_COND_AT): Add
__builtin_expect.
(_GLIBCXX_DEBUG_VERIFY_AT_F): Use __glibcxx_assert_1.
* testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc:
New test.
* testsuite/21_strings/basic_string_view/element_access/char/constexpr.cc: New test.
* testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc: New test.
* testsuite/21_strings/basic_string_view/element_access/char/front_back_constexpr.cc:
New test.
* testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc:
New test.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc:
New test.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr.cc: New test.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc: New test.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc:
New test.
* testsuite/25_algorithms/lower_bound/debug/constexpr_partitioned_neg.cc: New test.
* testsuite/25_algorithms/lower_bound/debug/constexpr_partitioned_pred_neg.cc: New test.
* testsuite/25_algorithms/lower_bound/debug/constexpr_valid_range_neg.cc: New test.
* testsuite/25_algorithms/lower_bound/debug/partitioned_neg.cc: New test.
* testsuite/25_algorithms/lower_bound/debug/partitioned_pred_neg.cc: New test.
* testsuite/25_algorithms/upper_bound/debug/constexpr_partitioned_neg.cc: New test.
* testsuite/25_algorithms/upper_bound/debug/constexpr_partitioned_pred_neg.cc: New test.
* testsuite/25_algorithms/upper_bound/debug/constexpr_valid_range_neg.cc: New test.
* testsuite/25_algorithms/upper_bound/debug/partitioned_neg.cc: New test.
* testsuite/25_algorithms/upper_bound/debug/partitioned_pred_neg.cc: New test.
The popcount built-ins work fine for zero, so there's no need to check
for it.
libstdc++-v3/ChangeLog:
* include/std/bit (__popcount): Remove redundant check for zero.
The std::function code now uses std::type_info* even when RTTI is
disabled, so it should include <typeinfo> unconditionally. Without this,
Clang can't compile <functional> with -fno-rtti (it works with GCC
because std::type_info gets declared automatically by the compiler).
libstdc++-v3/ChangeLog:
PR libstdc++/97758
* include/bits/std_function.h [!__cpp_rtti]: Include <typeinfo>.
The relational operators for std::optional were using the wrong types
in the declval expressions used to constrain them. Instead of using
const lvalues they were using non-const rvalues, which meant that a type
might satisfy the constraints but then give an error when the function
body was instantiated.
libstdc++-v3/ChangeLog:
PR libstdc++/96269
* include/std/optional (operator==, operator!=, operator<)
(operator>, operator<=, operator>=): Fix types used in
SFINAE constraints.
* testsuite/20_util/optional/relops/96269.cc: New test.
This fixes some multiple definition errors caused by the changes for
PR libstdc++/90295. The previous solution for inlining the members of
std::exception_ptr but still exporting them from the library was to
suppress the 'inline' keyword on those functions when compiling
libsupc++/eh_ptr.cc, so they get defined in that file. That produces ODR
violations though, because there are now both inline and non-inline
definitions in the library, due to the use of std::exception_ptr in
other files sucg as src/c++11/future.cc.
The new solution is to define all the relevant members as 'inline'
unconditionally, but use __attribute__((used)) to cause definitions to
be emitted in libsupc++/eh_ptr.cc as before. This doesn't quite work
however, because PR c++/67453 means the attribute is ignored on
constructors and destructors. As a workaround, the old solution
(conditionally inline) is still used for those members, but they are
given the always_inline attribute so that they aren't emitted in
src/c++11/future.o as inline definitions.
libstdc++-v3/ChangeLog:
PR libstdc++/97729
* include/std/future (__basic_future::_M_get_result): Use
nullptr for null pointer constant.
* libsupc++/eh_ptr.cc (operator==, operator!=): Remove
definitions.
* libsupc++/exception_ptr.h (_GLIBCXX_EH_PTR_USED): Define
macro to conditionally add __attribute__((__used__)).
(operator==, operator!=, exception_ptr::exception_ptr())
(exception_ptr::exception_ptr(const exception_ptr&))
(exception_ptr::~exception_ptr())
(exception_ptr::operator=(const exception_ptr&))
(exception_ptr::swap(exception_ptr&)): Always define as
inline. Add macro to be conditionally "used".
- Add a missing 'explicit' to a basic_stringbuf constructor.
- Set up the get/put area pointers in the constructor from strings using
different allocator types.
- Remove public basic_stringbuf::__sv_type alias.
- Do not construct temporary basic_string objects with a
default-constructed allocator.
Also, change which basic_string constructor is used, as a minor
compile-time optimization. Constructing from a basic_string_view
requires more work from the compiler, so just use a pointer and length.
libstdc++-v3/ChangeLog:
* include/std/sstream (basic_stringbuf(const allocator_type&):
Add explicit.
(basic_stringbuf(const basic_string<C,T,SA>&, openmode, const A&)):
Call _M_stringbuf_init. Construct _M_string from pointer and length
to avoid constraint checks for string view.
(basic_stringbuf::view()): Make __sv_type alias local to the
function.
(basic_istringstream(const basic_string<C,T,SA>&, openmode, const A&)):
Pass string to _M_streambuf instead of constructing a temporary
with the wrong allocator.
(basic_ostringstream(const basic_string<C,T,SA>&, openmode, const A&)):
Likewise.
(basic_stringstream(const basic_string<C,T,SA>&, openmode, const A&)):
Likewise.
* src/c++20/sstream-inst.cc: Use string_view and wstring_view
typedefs in explicit instantiations.
* testsuite/27_io/basic_istringstream/cons/char/1.cc: Add more
tests for constructors.
* testsuite/27_io/basic_ostringstream/cons/char/1.cc: Likewise.
* testsuite/27_io/basic_stringbuf/cons/char/1.cc: Likewise.
* testsuite/27_io/basic_stringbuf/cons/char/2.cc: Likewise.
* testsuite/27_io/basic_stringbuf/cons/wchar_t/1.cc: Likewise.
* testsuite/27_io/basic_stringbuf/cons/wchar_t/2.cc: Likewise.
* testsuite/27_io/basic_stringstream/cons/char/1.cc: Likewise.
Clang and EDG say the class member access expressions __urng.min() and
__urng.max() are not constant expressions, because the object expression
__urng is not usable in a constant expresion. Use a qualified-id to call
those static member functions instead.
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/uniform_int_dist.h (uniform_int_distribution::_S_nd):
Use qualified-id to refer to static member functions.
The current implementation of std::call_once uses pthread_once, which
only meets the C++ requirements when compiled with support for
exceptions. For most glibc targets and all non-glibc targets,
pthread_once does not work correctly if the init_routine exits via an
exception. The pthread_once_t object is left in the "active" state, and
any later attempts to run another init_routine will block forever.
This change makes std::call_once work correctly for Linux targets, by
replacing the use of pthread_once with a futex, based on the code from
__cxa_guard_acquire. For both glibc and musl, the Linux implementation
of pthread_once is already based on futexes, and pthread_once_t is just
a typedef for int, so this change does not alter the layout of
std::once_flag. By choosing the values for the int appropriately, the
new code is even ABI compatible. Code that calls the old implementation
of std::call_once will use pthread_once to manipulate the int, while new
code will use the new std::once_flag members to manipulate it, but they
should interoperate correctly. In both cases, the int is initially zero,
has the lowest bit set when there is an active execution, and equals 2
after a successful returning execution. The difference with the new code
is that exceptional exceptions are correctly detected and the int is
reset to zero.
The __cxa_guard_acquire code (and musl's pthread_once) use an additional
state to say there are other threads waiting. This allows the futex wake
syscall to be skipped if there is no contention. Glibc doesn't use a
waiter bit, so we have to unconditionally issue the wake in order to be
compatible with code calling the old std::call_once that uses Glibc's
pthread_once. If we know that we're using musl (and musl's pthread_once
doesn't change) it would be possible to set a waiting state and check
for it in std::once_flag::_M_finish(bool), but this patch doesn't do
that.
This doesn't fix the bug for non-linux targets. A similar approach could
be used for targets where we know the definition of pthread_once_t is a
mutex and an integer. We could make once_flag._M_activate() use
pthread_mutex_lock on the mutex member within the pthread_once_t, and
then only set the integer if the execution finishes, and then unlock the
mutex. That would require careful study of each target's pthread_once
implementation and that work is left for a later date.
This also fixes PR 55394 because pthread_once is no longer needed, and
PR 84323 because the fast path is now just an atomic load.
As a consequence of the new implementation that doesn't use
pthread_once, we can also make std::call_once work for targets with no
gthreads support. The code for the single-threaded implementation
follows the same methods as on Linux, but with no need for atomics or
futexes.
libstdc++-v3/ChangeLog:
PR libstdc++/55394
PR libstdc++/66146
PR libstdc++/84323
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols.
* include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define
even when gthreads is not supported.
(once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type
from __gthread_once_t to int.
(once_flag::_M_passive(), once_flag::_M_activate())
(once_flag::_M_finish(bool), once_flag::_Active_execution):
Define new members for futex and non-threaded implementation.
[_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New
RAII helper type.
(call_once): Use new members of once_flag.
* src/c++11/mutex.cc (std::once_flag::_M_activate): Define.
(std::once_flag::_M_finish): Define.
* testsuite/30_threads/call_once/39909.cc: Do not require
gthreads.
* testsuite/30_threads/call_once/49668.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/call_once/call_once1.cc: Likewise.
* testsuite/30_threads/call_once/dr2442.cc: Likewise.
* testsuite/30_threads/call_once/once_flag.cc: Add test for
constexpr constructor.
* testsuite/30_threads/call_once/66146.cc: New test.
* testsuite/30_threads/call_once/constexpr.cc: Removed.
* testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.
This meets the requirement that std::is_integral_v<wchar_t> is true,
even when full library support for wchar_t via specializations of
char_traits etc. is not provided. This is done by checking
__WCHAR_TYPE__ to see if the compiler knows about the type, rather than
checking the library's own _GLIBCXX_USE_WCHAR_T autoconf macro.
This assumes that the C++ compiler correctly defines wchar_t as a
distinct type, not a typedef for one of the other integeral types. This
is always true for G++ and should be true for any supported non-GNU
compilers.
Similarly, the std::make_unsigned and std::make_signed traits and the
internal helpers std::__is_integer and std::__is_char are also changed
to depend on the same macro.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_integral<wchar_t>)
(make_unsigned<wchar_t>, make_signed<wchar_t>): Define based
on #ifdef __WCHAR_TYPE__ instead of _GLIBCXX_USE_WCHAR_T.
* include/bits/cpp_type_traits.h (__is_integer<wchar_t>)
(__is_char<wchar_t>): Likewise.
The transition algorithm for std::shuffle_order_engine uses long double
to ensure that the value (max() - min() + 1) can be accurately
represented, to avoid bias in the shuffling. However, when the base
engine's range is small enough we can avoid slower long double
arithmetic by using double. For example, long double is unnecessary for
any base engine returning 32-bit values.
This makes std::knuth_b::operator() about 15% faster on x86_64, and
probably even more on targets where long double uses soft-float.
libstdc++-v3/ChangeLog:
* include/bits/random.h (independent_bit_engine): Fix typo
in comment.
(shuffle_order_engine): Fix incorrect description in comment.
* include/bits/random.tcc (__representable_as_double
(__p1_representable_as_double): New helper functions.
(shuffle_order_engine::operator()): Use double for calculation
if (max() - min() + 1) is representable as double.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
My previous commit for this PR changed the types from long double to
double, but didn't change the uses of __builtin_ceill and
__builtin_floorl. It also failed to change the non-inline functions in
src/c++11/hashtable_c++0x.cc. This should fix it properly now.
libstdc++-v3/ChangeLog:
PR libstdc++/96958
* include/bits/hashtable_policy.h (_Prime_rehash_policy)
(_Power2_rehash_policy): Use ceil and floor instead of ceill and
floorl.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy): Likewise.
Use double instead of long double.
This works around a subtle issue where instantiating the begin()/end()
member of some views (as part of return type deduction) inadvertently
requires computing the satisfaction value of range<foo_view>.
This is problematic because the constraint range<foo_view> requires the
begin()/end() member to be callable. But it's not callable until we've
deduced its return type, so evaluation of range<foo_view> yields false
at this point. And if after both members are instantiated (and their
return types deduced) we evaluate range<foo_view> again, this time it
will yield true since the begin()/end() members are now both callable.
This makes the program ill-formed according to [temp.constr.atomic]/3:
If, at different points in the program, the satisfaction result is
different for identical atomic constraints and template arguments, the
program is ill-formed, no diagnostic required.
The views affected by this issue are those whose begin()/end() member
has a placeholder return type and that member initializes an _Iterator
or _Sentinel object from a reference to *this. The second condition is
relevant because it means explicit conversion functions are considered
during overload resolution (as per [over.match.copy], I think), and
therefore it causes g++ to check the constraints of the conversion
function view_interface<foo_view>::operator bool(). And this conversion
function's constraints indirectly require range<foo_view>.
This issue is observable on trunk only with basic_istream_view (as in
the testcase in the PR). But a pending patch that makes g++ memoize
constraint satisfaction values indefinitely (it currently invalidates
the satisfaction cache on various events) causes many existing tests for
the other affected views to fail, because range<foo_view> then remains
false for the whole compilation.
This patch works around this issue by adjusting the constructors of the
_Iterator and _Sentinel types of the affected views to take their
foo_view argument by pointer instead of by reference, so that g++ no
longer considers explicit conversion functions when resolving the
direct-initialization inside these views' begin()/end() members.
libstdc++-v3/ChangeLog:
PR libstdc++/97600
* include/std/ranges (basic_istream_view::begin): Initialize
_Iterator from 'this' instead of '*this'.
(basic_istream_view::_Iterator::_Iterator): Adjust constructor
accordingly.
(filter_view::_Iterator::_Iterator): Take a filter_view*
argument instead of a filter_view& argument.
(filter_view::_Sentinel::_Sentinel): Likewise.
(filter_view::begin): Initialize _Iterator from 'this' instead
of '*this'.
(filter_view::end): Likewise.
(transform_view::_Iterator::_Iterator): Take a _Parent* instead
of a _Parent&.
(filter_view::_Iterator::operator+): Adjust accordingly.
(filter_view::_Iterator::operator-): Likewise.
(filter_view::begin): Initialize _Iterator from 'this' instead
of '*this'.
(filter_view::end): Likewise.
(join_view::_Iterator): Take a _Parent* instead of a _Parent&.
(join_view::_Sentinel): Likewise.
(join_view::begin): Initialize _Iterator from 'this' instead of
'*this'.
(join_view::end): Initialize _Sentinel from 'this' instead of
'*this'.
(split_view::_OuterIter): Take a _Parent& instead of a _Parent*.
(split_view::begin): Initialize _OuterIter from 'this' instead
of '*this'.
(split_view::end): Likewise.
* testsuite/std/ranges/97600.cc: New test.
This makes some range adaptors model the borrowed_range concept if they
are adapting a borrowed range. This hasn't been added to the C++23
working paper yet, but it has been approved by LWG, and the
recommendation is to treat it as a defect report for C++20 as well.
libstdc++-v3/ChangeLog:
* include/std/ranges (enable_borrowed_view<take_view<T>>)
(enable_borrowed_view<drop_view<T>>)
(enable_borrowed_view<drop_while_view<T>>)
(enable_borrowed_view<reverse_view<T>>)
(enable_borrowed_view<common_view<T>>)
(enable_borrowed_view<elements_view<T>>): Add partial
specializations as per P2017R1.
* testsuite/std/ranges/adaptors/conditionally_borrowed.cc:
New test.
These calculations were changed to use long double nearly ten years ago
in order to get more precision than float:
https://gcc.gnu.org/pipermail/libstdc++/2011-September/036420.html
However, double should be sufficient, whlie being potentially faster
than long double, and not requiring soft FP calculations for targets
without native long double support.
libstdc++-v3/ChangeLog:
PR libstdc++/96958
* include/bits/hashtable_policy.h (_Prime_rehash_policy)
(_Power2_rehash_policy): Use double instead of long double.
The class template semiregular-box<T> of [range.semi.wrap] is specified
to value-initialize the underlying object whenever its type is default
initializable. Our primary template for __detail::__box respects this
requirement, but the recently added partial specialization (for types
that are already semiregular) does not.
This patch fixes this issue, and additionally makes the corresponding in
place constructor explicit (as in the primary template).
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__box): For the partial
specialization used by types that are already semiregular,
make the default constructor value-initialize the underlying
object instead of default-initializing it. Make its in place
constructor explicit.
* testsuite/std/ranges/adaptors/detail/semiregular_box.cc:
Augment test.
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (subrange::subrange(R&&)): Use
direct-initialization instead of list-initialization, so a
potential narrowing conversion from ranges::size(r) to the
stored size isn't ill-formed.
These are usually suppressed in system headers, but should be fixed
anyway.
libstdc++-v3/ChangeLog:
* include/bits/parse_numbers.h (_Select_int_base): Avoid
narrowing conversion in constant expression.
* include/experimental/buffer (buffer_copy): Avoid narrowing
conversion.
* include/experimental/internet (hash<>::operator()): Do not
use deprecated 'argument_type' member.
* include/std/variant (variant::emplace): Use cast instead
of implicit conversion from size_t to narrower unsigned type.
This extends the fast path to also work when the URBG's range of
possible values is not the entire range of its result_type. Previously,
the slow path would be used for engines with a uint_fast32_t result type
if that type is actually a typedef for uint64_t rather than uint32_t.
After this change, the generator's result_type is not important, only
the range of possible value that generator can produce. If the
generator's range is exactly UINT64_MAX then the calculation will be
done using 128-bit and 64-bit integers, and if the range is UINT32_MAX
it will be done using 64-bit and 32-bit integers.
In practice, this benefits most of the engines and engine adaptors
defined in [rand.predef] on x86_64-linux and other 64-bit targets. This
is because std::minstd_rand0 and std::mt19937 and others use
uint_fast32_t, which is a typedef for uint64_t.
The code now makes use of the recently-clarified requirement that the
generator's min() and max() functions are usable in constant
expressions (see LWG 2154).
libstdc++-v3/ChangeLog:
* include/bits/uniform_int_dist.h (_Power_of_two): Add
constexpr.
(uniform_int_distribution::_S_nd): Add static_assert to ensure
the wider type is twice as wide as the result type.
(uniform_int_distribution::__generate_impl): Add static_assert
and declare variables as constexpr where appropriate.
(uniform_int_distribution:operator()): Likewise. Only consider
the uniform random bit generator's range of possible results
when deciding whether _S_nd can be used, not the __uctype type.
The rope extension uses a volatile variable for its reference count.
This is not only unnecessary for correctness (volatile provides neither
atomicity nor memory visibility, and the variable is only modified while
a lock is held) but it now causes deprecated warnings with
-Wsystem-headers due to the use of ++ and -- operators.
It would be possible to use __gnu_cxx::__exchange_and_add in _M_incr and
_M_decr when __atomic_is_lock_free(sizeof(_RC_t), &_M_ref_count) is
true, rather than locking a mutex. That would probably be a significant
improvement for multi-threaded and single-threaded code (because
__exchange_and_add will use non-atomic ops when possible, and even in MT
code it should be faster than the mutex lock/unlock pair). However,
mixing objects compiled with the old and new code would result in
inconsistent synchronization being used for the reference count.
libstdc++-v3/ChangeLog:
* include/ext/rope (_Refcount_Base::_M_ref_count): Remove
volatile qualifier.
(_Refcount_Base::_M_decr()): Likewise.
This change allows std::function::target<F>() to work even without RTTI,
using the same approach as std::any. Because we know what the manager
function would be for a given type, we can check if the stored pointer
has the expected address. If it does, we don't need to use RTTI. If it
isn't equal, we still need to do the RTTI check (when RTTI is enabled)
to handle the case where the same function has different addresses in
different shared objects.
This also changes the implementation of the manager function to return a
null pointer result when asked for the type_info of the target object.
This not only avoids a warning with -Wswitch -Wsystem-headers, but also
avoids prevents std::function::target_type() from dereferencing an
uninitialized pointer when the linker keeps an instantiation of the
manager function that was compiled without RTTI.
Finally, this fixes a bug in the non-const overload of function::target
where calling it with a function type F was ill-formed, due to
attempting to use const_cast<F*>(ptr). The standard only allows
const_cast<T*> when T is an object type. The solution is to use
*const_cast<F**>(&ptr) instead, because F* is an object type even if F
isn't. I've also used _GLIBCXX17_CONSTEXPR in function::target so that
it doesn't bother instantiating anything for types that can never be a
valid target.
libstdc++-v3/ChangeLog:
* include/bits/std_function.h (_Function_handler<void, void>):
Define explicit specialization used for invalid target types.
(_Base_manager::_M_manager) [!__cpp_rtti]: Return null.
(function::target_type()): Check for null pointer.
(function::target()): Define unconditionall. Fix bug with
const_cast of function pointer type.
(function::target() const): Define unconditionally, but
only use RTTI if enabled.
* testsuite/20_util/function/target_no_rtti.cc: New test.
The paper P0346R1 renamed uniform random number generators to
uniform random bit generators, to describe their purpose more
accurately. This makes that same change in one of the relevant
files (but not the others).
libstdc++-v3/ChangeLog:
* include/bits/uniform_int_dist.h (uniform_int_distribution):
Rename _UniformRandomNumberGenerator template parameters to
_UniformRandomBitGenerator, as per P0346R1.
libstdc++-v3/ChangeLog:
* include/std/sstream (basic_stringbuf(__string_type&&, openmode)):
Call _M_init_syncbuf to set up get/put areas. Also qualify
std::move.
The conversion function year_month_weekday::operator sys_days computes
the offset in days from the first weekday of the month with:
days{(index()-1)*7}
^~~~~~~~~~~~~ type 'unsigned'
We want the above to yield -7d when index() is 0u, but our 'days' alias
is based on long instead of int, so the conversion from unsigned to the
underlying type of 'days' instead yields a large positive value.
This patch fixes this by casting the result of index() to int so that
the initializer is sign-extended in the conversion to long.
The added testcase also verifies we do the right thing when index() == 5.
libstdc++-v3/ChangeLog:
PR libstdc++/96713
* include/std/chrono (year_month_weekday::operator sys_days):
Cast the result of index() to int so that the initializer for
days{} is sign-extended when it's converted to the underlying
type.
* testsuite/std/time/year_month_weekday/3.cc: New test.
This replaces uses of BUFSIZ with a new _GLIBCXX_BUFSIZ macro that can
be overridden in target-specific config headers.
That allows the mingw and mingw-w64 targets to override it, because
BUFSIZ is apparently defined to 512, resulting in poor performance. The
MSVCRT stdio apparently uses 4096, so we use that too.
libstdc++-v3/ChangeLog:
PR libstdc++/94268
* config/os/mingw32-w64/os_defines.h (_GLIBCXX_BUFSIZ):
Define.
* config/os/mingw32/os_defines.h (_GLIBCXX_BUFSIZ):
Define.
* include/bits/fstream.tcc: Use _GLIBCXX_BUFSIZ instead
of BUFSIZ.
* include/ext/stdio_filebuf.h: Likewise.
* include/std/fstream (_GLIBCXX_BUFSIZ): Define.
This replaces unqualified names like _Cosh with struct std::_Cosh to
ensure there is no ambiguity with other entities with the same name.
libstdc++-v3/ChangeLog:
PR libstdc++/95592
* include/bits/valarray_after.h (_DEFINE_EXPR_UNARY_OPERATOR)
(_DEFINE_EXPR_BINARY_OPERATOR, _DEFINE_EXPR_BINARY_FUNCTION):
Use elaborated-type-specifier and qualified-id to avoid
ambiguities with QNX system headers.
* testsuite/26_numerics/valarray/95592.cc: New test.
This change reorders the data members of std::span so that span<byte> is
layout-compatible with common implementations of struct iovec. This will
allow span<byte> to be used directly in places that use a struct iovec
to do scatter-gather I/O.
It's important to note that POSIX doesn't specify the order of members
in iovec. Also the equivalent type on Windows has members in the other
order, and uses type ULONG (which is always 32-bit whereas size_t is
64-bit for Win64). So this change will only help for certain targets and
an indirection between std::span and I/O system calls will still be
needed for the general case.
libstdc++-v3/ChangeLog:
PR libstdc++/95609
* include/std/span (span): Reorder data members to match common
implementations of struct iovec.
* testsuite/23_containers/span/layout_compat.cc: New test.
