These tests started failing at some point:
FAIL: 25_algorithms/copy/debug/constexpr_neg.cc (test for errors, line 49)
FAIL: 25_algorithms/copy/debug/constexpr_neg.cc (test for excess errors)
FAIL: 25_algorithms/equal/debug/constexpr_neg.cc (test for errors, line 47)
FAIL: 25_algorithms/equal/debug/constexpr_neg.cc (test for excess errors)
They only run with -D_GLIBCXX_DEBUG or make check-debug so seem to have
gone unnoticed until now.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/copy/debug/constexpr_neg.cc: Adjust
expected errors.
* testsuite/25_algorithms/equal/debug/constexpr_neg.cc:
Likewise.
Fix ordering to prevent clobbering of class members by a call to deallocate
in _M_realloc_insert and _M_default_append.
Because of recent changes in _M_realloc_insert and _M_default_append,
calls to deallocate were ordered after assignment to class members of
std::vector (in the guard destructor), which is causing said members to
be call-clobbered. This is preventing further optimization, the
compiler is unable to move memory read out of a hot loop in this case.
This patch reorders the call to before assignments by putting guard in
its own block. Plus a new testsuite for this case. I'm not very happy
with the new testsuite, but I don't know how to properly test this.
PR libstdc++/110879
libstdc++-v3/ChangeLog:
* include/bits/vector.tcc (_M_realloc_insert): End guard
lifetime just before assignment to class members.
(_M_default_append): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/pr110879.C: New test.
Signed-off-by: Vladimir Palevich <palevichva@gmail.com>
There are a few places in the std::filesystem code that use a string as
a buffer for OS APIs to write to. We can use the new extension
__resize_and_overwrite to avoid redundant initialization of those
buffers.
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (fs::absolute) [FILESYSTEM_IS_WINDOWS]:
Use __resize_and_overwrite to fill buffer.
(fs::read_symlink) [HAVE_READLINK]: Likewise.
* src/filesystem/ops-common.h (get_temp_directory_from_env)
[FILESYSTEM_IS_WINDOWS]: Likewise.
We need to use a loop in std::atomic_ref::compare_exchange_strong in
order to properly implement the C++20 requirement that padding bits do
not participate when checking the value for equality. The variable being
modified by a std::atomic_ref might have an initial value with non-zero
padding bits, so when the __atomic_compare_exchange built-in returns
false we need to check whether that was only because of non-equal
padding bits that are not part of the value representation. If the value
bits differ, it's just a failed compare-exchange. If the value bits are
the same, we need to retry the __atomic_compare_exchange using the value
that was just read by the previous failed call. As noted in the
comments, it's possible for that second try to also fail due to another
thread storing the same value but with differences in padding.
Because it's undefined to access a variable directly while it's held by
a std::atomic_ref, and because std::atomic_ref will only ever store
values with zeroed padding, we know that padding bits will never go from
zero to non-zero during the lifetime of a std::atomic_ref. They can only
go from an initial non-zero state to zero. This means the loop will
terminate, rather than looping indefinitely as padding bits flicker on
and off. In theory users could call __atomic_store etc. directly and
write a value with non-zero padding bits, but we don't need to support
that. Users doing that should ensure they do not write non-zero padding,
to be compatibile with our std::atomic_ref's invariants.
This isn't a problem for std::atomic<T>::compare_exchange_strong because
the initial value (and all later stores to the variable) are performed
by the library, so we ensure that stored values always have padding bits
cleared. That means we can simply clear the padding bits of the
'expected' value and we will be comparing two values with equal padding
bits. This means we don't need the loop for std::atomic, so update the
__atomic_impl::__compare_exchange function to take a bool parameter that
says whether it's being used by std::atomic_ref. If not, we can use a
simpler, non-looping implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/111077
* include/bits/atomic_base.h (__atomic_impl::__compare_exchange):
Add _AtomicRef non-type template parameter and use a loop if it
is true.
(__atomic_impl::compare_exchange_weak): Add _AtomicRef NTTP.
(__atomic_impl::compare_exchange_strong): Likewise.
(atomic_ref::compare_exchange_weak): Use true for NTTP.
(atomic_ref::compare_exchange_strong): Use true for NTTP.
* testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc:
Fix test to not rely on atomic_ref::load() to return an object
with padding preserved.
This test expects to be able to link, which fails if there are undefined
references to chdir, mkdir etc. in fs_ops.o in the libstdc++.a archive.
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/path/108636.cc: Add dg-require for
filesystem support.
chrono::tzdb::current_zone uses filesystem::read_symlink, which creates
a dependency on the fs_ops.o object in libstdc++.a, which then creates
dependencies on several OS functions if --gc-sections isn't used. For
more details see PR libstdc++/104167 comment 8 and comment 11.
In the cases where that causes linker failures, we probably don't have
readlink anyway, so the filesystem::read_symlink call will always fail.
Repeat the preprocessor conditions for filesystem::read_symlink in the
body of chrono::tzdb::current_zone so that we don't create a
dependency on fs_ops.o for a function that will always fail.
libstdc++-v3/ChangeLog:
* src/c++20/tzdb.cc (tzdb::current_zone): Check configure macros
for POSIX readlink before using filesystem::read_symlink.
This causes libstdc++_libbacktrace.a to be built by default. This might
fail on some targets, in which case we can make the 'auto' choice expand
to either 'yes' or 'no' depending on the target.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
* configure: Regenerate.
We fail to diagnose an error and extract an incorrect time for cases
like "25:59" >> parse("%H:%M", mins). The bad "25" hour value gets
ignored (on the basis that we might not care about it if trying to
extract something like a weekday or a month name), but then when we get
to the end of the function we think we have a valid time from "59" and
so the result is 00:59.
The problem is that the '__bad_h' value is used for "no hour value read
yet" as well as "bad hour value read". If we just set __h = __bad_h and
continue, we can't tell later that we read an invalid hour.
The fix is to set failbit early when we're trying to extract a
time-of-day (e.g. duration or time_point) and we encounter an invalid
hour, minute, or second value. We can still delay other error checking
to the end.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (_Parser::operator()): Set failbit
early if invalid values are read when _M_need & _TimeOfDay is
non-zero.
* testsuite/std/time/parse.cc: Check that "25:59" cannot be
parsed for "%H:%M".
libstdc++-v3/ChangeLog:
PR libstdc++/111162
* include/bits/chrono_io.h (_Parser::Operator()): Check %C
values are in range of year::min() to year::max().
* testsuite/std/time/parse.cc: Check out of range centuries.
Using an offset as the second argument instead of an iterator makes it
easier for callers, as they don't need to create an lvalue span in order
to get an iterator from it for the _M_reset call.
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Sink::_M_reset): Change second
argument from iterator to offset.
When parsing a format string, the width is parsed into an unsigned short
but the result is not checked in the case the format string is not a
char string (such as a wide string). In case the parse fails, a null
pointer is returned which is used for pointer arithmetic which is
undefined behaviour.
Signed-off-by: Paul Dreik <gccpatches@pauldreik.se>
libstdc++-v3/ChangeLog:
PR libstdc++/111102
* include/std/format (__format::__parse_integer): Check for
non-null pointer.
Update a preprocessor condition using __cplusplus and _GLIBCXX_HOSTED
to use the relevant feature test macro for <syncstream>.
Also add comments to some conditions saying which C++ standard revision
the check corresponds to.
libstdc++-v3/ChangeLog:
* include/std/atomic: Add comment to #ifdef and fix indentation.
* include/std/ostream: Check __glibcxx_syncbuf instead of
__cplusplus and _GLIBCXX_HOSTED.
* include/std/thread: Add comment to #ifdef.
This is a no-op for libstdc++, because our intmax_t is a 64-bit type and
so is incapable of representing the largest and smallest ratios from
C++11, let alone the new ones. I've added them to the file anyway (and
defined the feature test macro) so that if somebody ports libstdc++ to a
target with 128-bit intmax_t then they'll be present.
libstdc++-v3/ChangeLog:
* include/bits/version.def (__cpp_lib_ratio): Define.
* include/bits/version.h: Regenerate.
* include/std/ratio (quecto, ronto, yocto, zepto)
(zetta, yotta, ronna, quetta): Define.
* testsuite/20_util/ratio/operations/ops_overflow_neg.cc: Adjust
dg-error line numbers.
Print the locale's name, except when it uses the same named C locale for
all categories except one, in which case print something like:
std::locale = "en_GB.UTF-8" with "LC_CTYPE=en_US.UTF-8"
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdLocalePrinter): New
printer class.
* testsuite/libstdc++-prettyprinters/locale.cc: New test.
As the PR says, including the template arguments in the GDB output of
these class templates can result in very long names, especially for
std::variant. You can use 'whatis' or other GDB commands to get details
of the type, we don't need to include it in the value.
We could consider including the type if it's not too long, but I think
consistency is better (and we already omit the template arguments for
std::vector and other class templates).
libstdc++-v3/ChangeLog:
PR libstdc++/110944
* python/libstdcxx/v6/printers.py (StdExpOptionalPrinter): Do
not show template arguments.
(StdVariantPrinter): Likewise.
* testsuite/libstdc++-prettyprinters/compat.cc: Adjust expected
output.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
Fix tests that are checking for an expected allocation plan. They are failing if
an allocation is taking place outside the test main.
libstdc++-v3/ChangeLog
* testsuite/util/replacement_memory_operators.h
(counter::scope): New, capture and reset counter count at construction and
restore it at destruction.
(counter::check_new): Add scope instantiation.
* testsuite/23_containers/unordered_map/96088.cc (main):
Add counter::scope instantiation.
* testsuite/23_containers/unordered_multimap/96088.cc (main): Likewise.
* testsuite/23_containers/unordered_multiset/96088.cc (main): Likewise.
* testsuite/23_containers/unordered_set/96088.cc (main): Likewise.
* testsuite/ext/malloc_allocator/deallocate_local.cc (main): Likewise.
* testsuite/ext/new_allocator/deallocate_local.cc (main): Likewise.
* testsuite/ext/throw_allocator/deallocate_local.cc (main): Likewise.
* testsuite/ext/pool_allocator/allocate_chunk.cc (started): New global.
(operator new(size_t)): Check started.
(main): Set/Unset started.
* testsuite/17_intro/no_library_allocation.cc: New test case.
This test case calls std::set_terminate while there is an active
exception. Since LWG 2111 it is unspecified which terminate handler is
used when std::nested_exception::rethrow_nested() calls std::terminate.
With libsupc++ the global handler changed by std::set_terminate is used,
but libc++abi uses the active exception's handler (the one that was
current when the exception was first thrown).
Adjust the test case so that it works with either implementation choice.
So that the process doesn't exit cleanly if std::terminate happens
sooner than expected, use a global variable to control when the "clean
terminate" behaviour happens.
libstdc++-v3/ChangeLog:
* testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:
Call std::set_terminate before throwing the nested exception.
In r14-3304-g1a566fddea212a and r14-3305-g6cf214b4fc97f5 I tried to
enable std::format for 16-bit float types before C++23. This causes
errors for targets where the types are defined but can't actually be
used, e.g. i686 without sse2.
Make the std::numeric_limits and std::formatter specializations for
_Float16 and __bfloat16_t depend on the __STDCPP_FLOAT16_T__ and
__STDCPP_BFLOAT16_T__ macros again, so they're only defined for C++23
when the type is fully supported. This is OK because the main point of
my earlier commits was to add better support for _Float32 and _Float64.
It seems fine for the new 16-bit types to only be supported for C++23,
as they were never present before GCC 13 anyway.
libstdc++-v3/ChangeLog:
PR target/111060
* include/std/format (formatter): Only define specializations
for 16-bit floating-point types for C++23.
* include/std/limits (numeric_limits): Likewise.
This is one more piece of the rework to make wchar_t support in
std::format depend on _GLIBCXX_USE_WCHAR_T.
In <format> the __to_wstring_numeric function is called with arguments
that aren't type-dependent, so a declaration needs to be available, or
the calls need to be guarded by _GLIBCXX_USE_WCHAR_T.
In <chrono> there is a similarly non-type-dependent call to std::format
with a wchar_t format string, which is ill-formed when the wchar_t
overloads of std::format are not declared. Use _GLIBCXX_WIDEN to make it
type-dependent.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (operator<<): Make uses of wide
strings with streams and std::format type-dependent on _CharT.
* include/std/format [!_GLIBCXX_USE_WCHAR_T] Do not use
__to_wstring_numeric.
r14-3300-g023a62b77f999b left make_wformat_args and some uses of
std::wformat_context unguarded by _GLIBCXX_USE_WCHAR_T.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (operator<<): Use __format_context.
* include/std/format (__format::__format_context): New alias
template.
[!_GLIBCXX_USE_WCHAR_T] (wformat_args, make_wformat_arg):
Disable.
When the library is built with --disable-libstdcxx-dual-abi the only
type of std::string supported is the COW string, and the two global
std::string objects in tzdb.cc have to allocate memory. I added them
thinking they would fit in the SSO string buffer, but that's not the
case when the library only uses COW strings.
Replace them with string_view objects to avoid any allocations.
libstdc++-v3/ChangeLog:
* src/c++20/tzdb.cc (tzdata_file, leaps_file): Change type to
std::string_view.
For targets where double and long double have the same representation we
can reuse the same __convert_to_v code for both types. This will
slightly reduce the size of the compiled code in the library.
libstdc++-v3/ChangeLog:
* config/locale/generic/c_locale.cc (__convert_to_v): Reuse
double overload for long double if possible.
This shaves about 100ns off the std::locale constructor for named
locales (which is only about 1% of the total time).
Using !*s instead of !strcmp(s, "") doesn't make any difference as GCC
optimizes that already even at -O1. !strcmp(s, "C") is optimized at -O2
so replacing that with s[0] == 'C' && s[1] == '\0' only matters for the
--enable-libstdcxx-debug builds. But !strcmp(s, "POSIX") always makes a
call to strcmp at any optimization level. We make that strcmp call,
maybe several times, for any locale name except for "C" (which will be
matched before we get to the check for "POSIX").
For most targets, locale names begin with a lowercase letter and the
only one that begins with 'P' is "POSIX". Replacing !strcmp(s, "POSIX")
with s[0] == 'P' && !strcmp(s+1, "OSIX") means that we avoid calling
strcmp unless the string really does match "POSIX".
Maybe more importantly, I find is_C_locale(s) easier to read than
strcmp(s, "C") == 0 || strcmp(s, "POSIX") == 0, and !is_C_locale(s)
easier to read than strcmp(s, "C") != 0 && strcmp(s, "POSIX") != 0.
libstdc++-v3/ChangeLog:
* src/c++98/localename.cc (is_C_locale): New function.
(locale::locale(const char*)): Use is_C_locale.
Calling string::assign(Iter, Iter) with "foreign" iterators (not the
string's own iterator or pointer types) currently constructs a temporary
string and then calls replace to copy the characters from it. That means
we copy from the iterators twice, and if the replace operation has to
grow the string then we also allocate twice.
By using *this = basic_string(first, last, get_allocator()) we only
perform a single allocation+copy and then do a cheap move assignment
instead of a second copy (and possible allocation). But that alternative
has to be done conditionally, so that we don't pessimize the native
iterator case (the string's own iterator and pointer types) which
currently select efficient overloads of replace which will not allocate
at all if the string already has sufficient capacity. For C++20 we can
extend that efficient case to work for any contiguous iterator with the
right value type, not just for the string's native iterators.
So the change is to inline the code that decides whether to work in
place or to allocate+copy (instead of deciding that via overload
resolution for replace), and for the allocate+copy case do a move
assignment instead of another call to replace.
For C++98 there is no change, as we can't do an efficient move
assignment anyway, so keep the current code.
We can also simplify assign(initializer_list<CharT>) because the backing
array for an initializer_list is always disjunct with *this, so most of
the code in _M_replace is not needed.
libstdc++-v3/ChangeLog:
PR libstdc++/110945
* include/bits/basic_string.h (basic_string::assign(Iter, Iter)):
Dispatch to _M_replace or move assignment from a temporary,
based on the iterator type.
This makes it possible to format _Float32, _Float64 etc. in C++20 mode.
Previously it was only possible to format them in C++23 when the
<stdfloat> typedefs and the std::to_chars overloads were defined.
Instead of relying on std::to_chars for those types, we can just reuse
the formatters for float, double and long double. This also avoids
template bloat by reusing the same specializations instead of
instantiating __formatter_fp for every different type.
libstdc++-v3/ChangeLog:
* include/std/format (formatter): Add partial specializations
for extended floating-point types.
* testsuite/std/format/functions/format.cc: Move test_float128()
to ...
* testsuite/std/format/formatter/ext_float.cc: New test.
The extended floating-point types such as _Float32 are supported by GCC
prior to C++23, you just can't use the standard-conforming names from
<stdfloat> to refer to them. This change defines the specializations of
std::numeric_limits for those types for older dialects, not only for
C++23.
libstdc++-v3/ChangeLog:
* include/bits/c++config (__gnu_cxx::__bfloat16_t): Define
whenever __BFLT16_DIG__ is defined, not only for C++23.
* include/std/limits (numeric_limits<bfloat16_t>): Likewise.
(numeric_limits<_Float16>, numeric_limits<_Float32>)
(numeric_limits<_Float64>): Likewise for other extended
floating-point types.
This constructor should only ever be used with a literal 0 as the
argument, so we can make it consteval. This has the nice advantage that
it is expanded immediately in the front end, and so GDB will never step
into the __cmp_cat::__unseq::__unseq(__unseq*) constructor that is
uninteresting and probably confusing to users.
libstdc++-v3/ChangeLog:
* libsupc++/compare (__cmp_cat::__unseq): Make ctor consteval.
* testsuite/18_support/comparisons/categories/zero_neg.cc: Prune
excess errors caused by invalid consteval calls.
For std::chrono formatting we can simplify __units_suffix by using
std::format_to to generate the "[n/m]s" suffix with the correct
character type and write directly to the output iterator, so it doesn't
need to be widened using ctype. We can't remove the use of ctype::widen
for formatting a time zone abbreviation as a wide string, because that
can contain arbitrary characters that can't be widened by
__to_wstring_numeric.
This also fixes a bug in the chrono formatter for %Z which created a
dangling wstring_view.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__units_suffix_misc): Remove.
(__units_suffix): Return a known suffix as string view, do not
write unknown suffixes to a buffer.
(__fmt_units_suffix): New function that formats the suffix using
std::format_to.
(operator<<, __chrono_formatter::_M_q): Use __fmt_units_suffix.
(__chrono_formatter::_M_Z): Correct lifetime of wstring.
This changes how std::format creates wide strings, by replacing uses of
std::ctype<wchar_t>::widen with the recently-added __to_wstring_numeric
helper function. This removes the dependency on the locale, which should
only be used for locale-specific formats such as {:Ld}.
Also disable all the wide string formatting support if the
_GLIBCXX_USE_WCHAR_T macro is not defined. This is consistent with other
wchar_t support being disabled if the library is built without that
macro defined.
libstdc++-v3/ChangeLog:
* include/std/format [_GLIBCXX_USE_WCHAR_T]: Guard all wide
string formatters with this macro.
(__formatter_int::_M_format_int, __formatter_fp::format)
(formatter<const void*, C>::format): Use __to_wstring_numeric
instead of std::ctype::widen.
(__formatter_fp::_M_localize): Use hardcoded wchar_t values
instead of std::ctype::widen.
* testsuite/std/format/functions/format.cc: Add more checks for
wstring formatting of arithmetic types.
This change for C++26 affects std::to_string for floating-point
arguments, so that they should be formatted using std::format("{}", v)
instead of using sprintf. The modified specification in the standard
also affects integral arguments, but there's no observable difference
for them, and we already use std::to_chars for them anyway.
To avoid <string> depending on all of <format>, this change actually
just uses std::to_chars directly instead of using std::format. This is
equivalent, because the format spec "{}" doesn't use any of the other
features of std::format.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (to_string(floating-point-type)):
Implement using std::to_chars for C++26.
* include/bits/version.def (__cpp_lib_to_string): Define.
* include/bits/version.h: Regenerate.
* testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:
Adjust expected result in C++26 mode.
* testsuite/21_strings/basic_string/numeric_conversions/char/to_string.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/to_wstring.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/to_string_float.cc:
New test.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/to_wstring_float.cc:
New test.
* testsuite/21_strings/basic_string/numeric_conversions/version.cc:
New test.
This uses std::string::__resize_and_overwrite to avoid initializing the
string buffer with characters that are immediately overwritten. This
results in about 6% better performance for the std_to_string case in
int-benchmark.cc from https://github.com/fmtlib/format-benchmark
This requires a change to a testcase. The previous implementation
guaranteed that the string returned from std::to_string(integral-type)
would have no excess capacity, because it was constructed with the
correct length. The new implementation constructs an empty string and
then resizes it with resize_and_overwrite, which over-allocates. This
means that the "no-excess capacity" guarantee no longer holds.
We can also greatly improve the performance of std::to_wstring by using
std::to_string and then widening it with a new helper function, instead
of using std::swprintf to do the formatting.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (to_string(integral-type)): Use
resize_and_overwrite when available.
(__to_wstring_numeric): New helper functions.
(to_wstring): Use std::to_string then __to_wstring_numeric.
* testsuite/21_strings/basic_string/numeric_conversions/char/to_string_int.cc:
Remove check for no excess capacity.
There are several places in the library where we can improve performance
using resize_and_overwrite so it's inconvenient only being able to use
it in C++23 mode, and only for cxx11 strings. This adds it for COW
strings, and also adds __resize_and_overwrite as an extension for C++11
mode.
The new __resize_and_overwrite is available for C++11 and later, so
within the library we can use that consistently even in C++23. In order
to avoid making a copy (which might not be possible for non-copyable,
non-movable types) the callable is passed to resize_and_overwrite as an
lvalue reference. Unlike wrapping it in std::ref(op) this ensures that
invoking it as std::move(op)(n, p) will use the correct value category.
It also avoids any overhead that would be added by wrapping it in a
lambda like [&op](auto p, auto n) { return std::move(op)(p, n); }.
Adjust std::format to use the new __resize_and_overwrite, which we can
assume exists because we only use std::basic_string<char> and
std::basic_string<wchar_t>, so no program-defined specializations.
The uses in <experimental/internet> cannot be replaced, because those
are type-dependent on an Allocator template parameter, which could mean
they use program-defined specializations of std::basic_string that don't
have the __resize_and_overwrite extension.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__resize_and_overwrite): New
function.
* include/bits/basic_string.tcc (__resize_and_overwrite): New
function.
(resize_and_overwrite): Simplify by using reserve instead of
growing the string manually. Adjust for C++11 compatibility.
* include/bits/cow_string.h (resize_and_overwrite): New
function.
(__resize_and_overwrite): New function.
* include/bits/version.def (__cpp_lib_string_resize_and_overwrite):
Do not depend on cxx11abi.
* include/bits/version.h: Regenerate.
* include/std/format (__formatter_fp::_S_resize_and_overwrite):
Remove.
(__formatter_fp::format, __formatter_fp::_M_localize): Use
__resize_and_overwrite instead of _S_resize_and_overwrite.
* testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite.cc:
Adjust for C++11 compatibility when included by ...
* testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite_ext.cc:
New test.
This C++23 paper fixes an issue in these views when adapting a certain
kind of non-forward range, and we treat it as a DR against C++20.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/regex.h (regex_iterator::iterator_concept):
Define for C++20 as per P2770R0.
(regex_token_iterator::iterator_concept): Likewise.
* include/std/ranges (__detail::__as_lvalue): Define.
(join_view::_Iterator): Befriend join_view.
(join_view::_Iterator::_M_satisfy): Use _M_get_outer
instead of _M_outer.
(join_view::_Iterator::_M_get_outer): Define.
(join_view::_Iterator::_Iterator): Split constructor taking
_Parent argument into two as per P2770R0. Remove constraint on
default constructor.
(join_view::_Iterator::_M_outer): Make this data member present
only when the underlying range is forward.
(join_view::_Iterator::operator++): Use _M_get_outer instead of
_M_outer.
(join_view::_Iterator::operator--): Use __as_lvalue helper.
(join_view::_Iterator::operator==): Adjust constraints as per
P2770R0.
(join_view::_Sentinel::__equal): Use _M_get_outer instead of
_M_outer.
(join_view::_M_outer): New data member when the underlying range
is non-forward.
(join_view::begin): Adjust definition as per P2770R0.
(join_view::end): Likewise.
(join_with_view::_M_outer_it): New data member when the
underlying range is non-forward.
(join_with_view::begin): Adjust definition as per P2770R0.
(join_with_view::end): Likewise.
(join_with_view::_Iterator::_M_outer_it): Make this data member
present only when the underlying range is forward.
(join_with_view::_Iterator::_M_get_outer): Define.
(join_with_view::_Iterator::_Iterator): Split constructor
taking _Parent argument into two as per P2770R0. Remove
constraint on default constructor.
(join_with_view::_Iterator::_M_update_inner): Adjust definition
as per P2770R0.
(join_with_view::_Iterator::_M_get_inner): Likewise.
(join_with_view::_Iterator::_M_satisfy): Adjust calls to
_M_get_inner. Use _M_get_outer instead of _M_outer_it.
(join_with_view::_Iterator::operator==): Adjust constraints
as per P2770R0.
(join_with_view::_Sentinel::operator==): Use _M_get_outer
instead of _M_outer_it.
* testsuite/std/ranges/adaptors/p2770r0.cc: New test.
Using the CRTP idiom for this base class avoids bloating the size of a
pipeline when adding distinct empty range adaptor closure objects to it,
as detailed in section 4.1 of P2387R3.
But it means we can no longer define its operator| overloads as hidden
friends, since it'd mean each instantiation of _RangeAdaptorClosure
introduces its own distinct set of hidden friends. So e.g. for the
outer | in
x | (views::reverse | views::join)
ADL would find 6 distinct hidden operator| friends:
two from _RangeAdaptorClosure<_Reverse>
two from _RangeAdaptorClosure<_Join>
two from _RangeAdaptorClosure<_Pipe<_Reverse, _Join>>
but we really only want to consider the last two.
We avoid this issue by instead defining the operator| overloads at
namespace scope alongside _RangeAdaptorClosure. This should be fine
because the only types defined in this namespace are _RangeAdaptorClosure,
_RangeAdaptor, _Pipe and _Partial, so we don't have to worry about
unintentional ADL.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/108827
libstdc++-v3/ChangeLog:
* include/std/ranges (__adaptor::_RangeAdaptorClosure):
Convert into a CRTP class template. Move hidden operator|
friends into namespace scope and adjust their constraints.
(__closure::__is_range_adaptor_closure_fn): Define.
(__closure::__is_range_adaptor_closure): Define.
(__adaptor::_Partial): Adjust use of _RangeAdaptorClosure.
(__adaptor::_Pipe): Likewise.
(views::_All): Likewise.
(views::_Join): Likewise.
(views::_Common): Likewise.
(views::_Reverse): Likewise.
(views::_Elements): Likewise.
(views::_Adjacent): Likewise.
(views::_AsRvalue): Likewise.
(views::_Enumerate): Likewise.
(views::_AsConst): Likewise.
* testsuite/std/ranges/adaptors/all.cc: Reinstate assertion
expecting that adding empty range adaptor closure objects to a
pipeline doesn't increase the size of a pipeline.
std::format was treating {:f} and {:F} identically on the basis that for
the fixed 1.234567 format there are no alphabetical characters that need
to be in uppercase. But that's wrong for infinities and NaNs, which
should be formatted as "INF" and "NAN" for {:F}.
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Pres_type): Add _Pres_F.
(__formatter_fp::parse): Use _Pres_F for 'F'.
(__formatter_fp::format): Set __upper for _Pres_F.
* testsuite/std/format/functions/format.cc: Check formatting of
infinity and NaN for each presentation type.
These tests expect to be able to #undef a feature test macro and then
include <version> to get it redefined. But if <version> has already been
included by the <bits/stdc++.h> PCH then including it again does nothing
and the macro remains undefined.
libstdc++-v3/ChangeLog:
* testsuite/24_iterators/move_iterator/p2520r0.cc: Add no_pch.
* testsuite/std/format/functions/format.cc: Likewise.
* testsuite/std/format/functions/format_c++23.cc: Likewise.
The { dg-add-options no_pch } directive is supposed to add a macro
definition that invalidates the PCH file, and ensures that the #include
directives in the test file are processed as written. But the proc that
adds the options actually removes all existing options, cancelling out
any previous dg-options directive.
This means that using no_pch will cause FAILs in a file that relies on
other options set by an earlier dg-options.
The no_pch directive was added for PR libstdc++/21769 where Janis
suggested adding it as return "$flags -D__GLIBCXX__=99999999" but what
was actually committed didn't include the $flags so replaced them.
Additionally, using no_pch only prevents the precompiled version of
<bits/stdc++.h> from being included, it doesn't prevent the
non-precompiled version being included by -include bits/stdc++.h in the
test flags. Use regsub to filter that out of the options as well.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (add_options_for_no_pch): Remove
any "-include bits/stdc++.h" from options and add the macro to
the existing options instead of replacing them.
