The preprocessor condition for using fast_float should match the one in
the header, and require at least 32-bit size_t.
libstdc++-v3/ChangeLog:
PR libstdc++/104870
* src/c++17/floating_from_chars.cc: Check __SIZE_WIDTH__ >= 32
before using fast_float.
I mistakenly believed that VAX floats do not support NaN, but with GCC
__builtin_isnan(__builtin_nan("")) is true. That means my previous
change to <compare> is wrong, because it fails to handle NaN.
When std::numeric_limits<floating-point-type>::is_iec559 is false, as on
VAX, the standard only requires an ordering that is consistent with the
ordering observed by comparison operators. With this change the ordering
is -NaN < numbers < +NaN, and there is no support for different NaN bit
patterns (as I'm not even sure if GCC supports any for VAX).
libstdc++-v3/ChangeLog:
* libsupc++/compare (_Strong_order::_S_fp_cmp) [__vax__]:
Handle NaN.
The VAX float and double format does not support NaN, so the
std::partial_ordering returned by <=> will never be 'unordered'. We can
just use the partial_ordering value as the strong_ordering.
libstdc++-v3/ChangeLog:
* libsupc++/compare (_Strong_ordering::_S_fp_cmp) [__vax__]: Use
<=> comparison.
We need to be explicit about narrowing conversions from uint128_t since,
on targets that lack __int128, this type is defined as an integer-class
type that is only _explicitly_ convertible to the builtin integer types.
This issue was latent until r12-7563-ge32869a17b788b made the frontend
correctly reject explicit conversion functions during (dependent)
copy-initialization.
PR libstdc++/104859
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
Be explicit when narrowing the shifted effective_mantissa,
since it may have an integer-class type.
This file has the SGI copyright notice, but contains no code from
the SGI STL. It was entirely written by me in 2019, originally as part
of the <memory> header. When I extracted it into a new header I
accidentally copied across the SGI copyright, but that only applies to
some much older parts of <memory>.
libstdc++-v3/ChangeLog:
* include/bits/uses_allocator_args.h: Remove incorrect copyright
notice.
The _GLIBCXX_PSEUDO_VISIBILITY macro isn't defined until after including
os_defines.h, so we can't use _GLIBCXX_VISIBILITY early in c++config.
Replace the uses of that macro with #pragma visibility push(default)
instead.
libstdc++-v3/ChangeLog:
PR libstdc++/104807
* include/bits/c++config (__terminate, __glibcxx_assert_fail):
Replace _GLIBCXX_VISIBILITY on function with visibility pragma.
(__is_constant_evaluated): Add visibility pragma.
There doesn't seem to be any reason for this TU to include
<iostream>, and it causes errors when the resulting libstdc++ is used
on our VxWorks 5.5 target - presumably because now libstdc++ itself
contains an instance of std::ios_base::Init. Which should be mostly
harmless, but apparently isn't, and from a QoI viewpoint should
probably be avoided anyway.
libstdc++-v3/ChangeLog:
* config/locale/vxworks/ctype_members.cc: Remove <iostream>
include.
This ensures there's no linker error if libstdc++ headers are included
following a pragma that sets hidden visibility.
Similarly for std::__terminate, which is always-inline so shouldn't
matter, but it's not wrong to do this anyway.
libstdc++-v3/ChangeLog:
* include/bits/c++config (__glibcxx_assert_fail): Add visibility
attribute.
(__terminate): Likewise.
The std::__debug::vector isn't usable in constant expressions, so this
test fails in debug mode. Until the debug vector is fixed we can just
make the test use the non-debug one.
libstdc++-v3/ChangeLog:
PR libstdc++/104748
* testsuite/std/ranges/adaptors/all.cc: Use non-debug vector for
constexpr test.
This fixes a test failure due to a non-reserved name in an AIX system
header (included via <pthread.h>). That name clashes with one of the
names we check our own headers for, so skip checking that name on AIX.
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc (func): Undef on AIX.
This removes a FIXME in <compare>, defining the total order for
floating-point types. I originally opened PR96526 to request a new
compiler built-in to implement this, but now that we have std::bit_cast
it can be done entirely in the library.
The implementation is based on the glibc definitions of totalorder,
totalorderf, totalorderl etc.
I think this works for all the types that satisfy std::floating_point
today, and should also work for the types expected to be added by P1467
except for std::bfloat16_t. It also supports some additional types that
don't currently satisfy std::floating_point, such as __float80, but we
probably do want that to satisfy the concept for non-strict modes.
libstdc++-v3/ChangeLog:
PR libstdc++/96526
* libsupc++/compare (strong_order): Add missing support for
floating-point types.
* testsuite/18_support/comparisons/algorithms/strong_order_floats.cc:
New test.
This fixes a false positive warning seen with LTO:
12/bits/regex_compiler.tcc:443:32: error: '__last_char._M_char' may be used uninitialized [-Werror=maybe-uninitialized]
Given that the std::regex code is not very efficient anyway, the
overhead of initializing this byte should be minimal.
libstdc++-v3/ChangeLog:
PR middle-end/103984
* include/bits/regex_compiler.h (_BracketMatcher::_M_char): Use
default member initializer.
This fixes a problem for Clang, which is going to return a non-void
pointer from __builtin_source_location(). The current definition of
std::source_location::current() converts that to void* and then has to
cast it back again in the body (which makes it invalid in a constant
expression). By using the actual type of the returned pointer, we avoid
the problematic cast for Clang.
libstdc++-v3/ChangeLog:
PR libstdc++/104602
* include/std/source_location (source_location::current): Use
deduced type of __builtin_source_location().
This implements the wording changes in P2415R2 "What is a view?", which
is a DR for C++20.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__detail::__is_initializer_list):
Define.
(viewable_range): Adjust as per P2415R2.
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value.
* include/std/ranges (owning_view): Define as per P2415R2.
(enable_borrowed_range<owning_view>): Likewise.
(views::__detail::__can_subrange): Replace with ...
(views::__detail::__can_owning_view): ... this.
(views::_All::_S_noexcept): Sync with operator().
(views::_All::operator()): Use owning_view instead of subrange
as per P2415R2.
* include/std/version (__cpp_lib_ranges): Adjust value.
* testsuite/std/ranges/adaptors/all.cc (test06): Adjust now that
views::all uses owning_view instead of subrange.
(test08): New test.
* testsuite/std/ranges/adaptors/lazy_split.cc (test09): Adjust
now that rvalue non-view non-borrowed ranges are viewable.
* testsuite/std/ranges/adaptors/split.cc (test06): Likewise.
The SGI STL and pre-1998 drafts of the C++ standard had a default
argument for vector<bool>::insert(iterator, const bool&) which was
remove by N1051. The default argument is still present in libstdc++ for
some reason. There are no tests verifying it as an extension, so I don't
think it has been kept intentionally.
This removes the default argument but adds an overload without the
second parameter, and adds the deprecated attribute to it. This allows
any code using it to keep working (for now) but with a warning.
libstdc++-v3/ChangeLog:
PR libstdc++/104559
* doc/xml/manual/evolution.xml: Document deprecation.
* doc/html/manual/api.html: Regenerate.
* include/bits/stl_bvector.h (insert(const_iterator, const bool&)):
Remove default argument.
(insert(const_iterator)): New overload with deprecated attribute.
* testsuite/23_containers/vector/bool/modifiers/insert/104559.cc:
New test.
This attempts to implement a partial workaround for the GDB bug
https://sourceware.org/bugzilla/show_bug.cgi?id=28856 which causes GDB
to crash when printing a frame with a std::error_code argument.
By recognising the known error categories defined in the library and
hardcoding their names we do not need to call cat->name() on the
category. This has the additional benefit of also working when
debugging a core file rather than a running process. For those known
categories we can also cast the int value to the corresponding error
code enum (e.g. future_errc) so that we show an enumerator instead of
just an integer.
For program-defined categories we just use the name of the dynamic type
to identify the category, and print the value as an integer. Once the
GDB bug is fixed and the virtual name() function can be called safely,
that would be preferable. For now it's better to have an imperfect
printer that doesn't crash GDB.
This rewritten StdErrorCodePrinter needs gdb.Value.dynamic_type, so is
only registered if that is supported, which means GDB 7.7 and later.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Replace
code that call cat->name() on std::error_category objects.
Identify known categories by symbol name and use a hardcoded
name. Print error code values as enumerators where appopriate.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Adjust expected
name of custom category. Check io_errc and future_errc errors.
The std::__convert_from_v helper that formats double and long double
values into a char buffer was not being duplicated for the two long
double ABIs. This resulted in an ODR violation inside the library, where
some callers needed it to use snprintf to format __ibm128 values and
other callers needed it to use __snprintfieee128 to format __ieee128
values. The linker discarded one of the definitions, leaving one set of
callers using the wrong code.
This puts __convert_from_v in the __gnu_cxx_ieee128 inline namespace
when long double is __ieee128, so that there are two different
definitions of the function.
The std::money_put::__do_put overload for __ibm128 values needs a
different fix, because that is defined when long double is __ieee128 and
so would call the one in the inline namespace. That can be fixed by just
inlining the code directly into the function and using an asm alias to
call the right version of snprintf for the __ibm128 format. The code to
do that can be simpler than __convert_from_v because if we're defining
the ALT128_COMPAT symbols we know that we have a recent glibc and so we
can assume that uselocale and snprintf are supported.
libstdc++-v3/ChangeLog:
PR libstdc++/100912
* config/locale/gnu/c_locale.h (__convert_from_v): Use inline
namespace for IEEE128 long double mode.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Add new symbol
version and export __gnu_cxx_ieee128::__convert_from_v.
* include/bits/locale_facets_nonio.tcc (money_put::__do_put):
Make __ibm128 overload use snprintf directly
* testsuite/util/testsuite_abi.cc: Add new symbol version.
Remove stable IEEE128/LDBL versions.
With the new value of __cpp_concepts required by P2493, we can test
whether the compiler supports conditionally trivial special members.
This allows us to remove the workaround that disables fully-constexpr
std::variant for Clang. Now it should work for non-GCC compilers (such
as future releases of Clang) that support conditionally trivial
destructors and define the new value of __cpp_concepts.
libstdc++-v3/ChangeLog:
PR libstdc++/103891
* include/bits/c++config (_GLIBCXX_HAVE_COND_TRIVIAL_SPECIAL_MEMBERS):
Remove.
* include/std/variant: Check feature test macros instead.
* include/std/version: Likewise.
The preprocessor check for _GLIBCXX_USE_FLOAT128 is the wrong condition,
because when the compiler is built with --with-long-double-format=ieee
configure determines that __float128 is the same as long double, and so
should not be used. But we do want the std::to_chars overloads for
__float128 in that case, because the floating_to_chars.cc file is built
with -mabi=ibmlongdouble and so the __float128 overloads are actually
the 'long double' ones for -mabi=ieeelongdouble code.
This fixes missing definitions of the __float128 overloads of
std::to_chars for --with-long-double-format=ieee builds. Without this,
there are symbols present in the --with-long-double-abi=ibm build which
are missing from the --with-long-double-abi=ieee build.
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (FLOAT128_TO_CHARS): Depend on
LONG_DOUBLE_ALT128_COMPAT instead of USE_FLOAT128.
The std::get_temporary_buffer function is deprecated since C++17, but
the test was expecting a warning for C++14 as well.
libstdc++-v3/ChangeLog:
* testsuite/20_util/temporary_buffer.cc: Fix dg-warning target
selector.
This changes the memory order used in the spin wait code to match
that of libc++.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__waiter_base::_S_do_spin,
__waiter_base::_S_do_spin_v): Change memory order from relaxed
to acquire.
This function (and the explicit memory over version) are present in both
C++ <atomic> and C <stdatomic.h>, so should be in C++ <stdatomic.h> too.
There is a library issue incoming for this, but the resolution is
obvious.
libstdc++-v3/ChangeLog:
* include/c_compatibility/stdatomic.h (atomic_fetch_xor): Add
using-declaration.
(atomic_fetch_xor_explicit): Likewise.
* testsuite/29_atomics/headers/stdatomic.h/c_compat.cc: Check
arithmetic and logical operations for atomic_int.
When building for newlib HAVE_OPENAT and HAVE_UNLINKAT are (sometimes?)
defined, but <fcntl.h> is only included when HAVE_DIRENT_H is defined.
Since directory iterators are completely useless without <dirent.h>,
just override the HAVE_OPENAT and HAVE_UNLINKAT detection when we don't
have <dirent.h>.
libstdc++-v3/ChangeLog:
* src/filesystem/dir-common.h (_GLIBCXX_HAVE_DIRFD): Undefine
when <dirent.h> is not available.
(_GLIBCXX_HAVE_UNLINKAT): Likewise.
This issue was observed as a deadlock in
29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
"laundered" (e.g. type T* does not suffice as a waitable address for the
platform's native waiting primitive), the address waited is that of the
_M_ver member of __waiter_pool_base, so several threads may wait on the
same address for unrelated atomic<T> objects. As noted in the PR, the
implementation correctly exits the wait for the thread whose data
changed, but not for any other threads waiting on the same address.
As noted in the PR the __waiter::_M_do_wait_v member was correctly exiting
but the other waiters were not reloading the value of _M_ver before
re-entering the wait.
Moving the spin call inside the loop accomplishes this, and is
consistent with the predicate accepting version of __waiter::_M_do_wait.
libstdc++-v3/ChangeLog:
PR libstdc++/104442
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): Move spin
loop inside do loop so that threads failing the wait, reload
_M_ver.
This replaces the _Dir constructor that takes ownership of an existing
DIR* resource with one that takes a _Dir_base rvalue instead. This means
a raw DIR* is never passed around, but is always owned by a _Dir_base
object.
libstdc++-v3/ChangeLog:
* src/c++17/fs_dir.cc (_Dir(DIR*, const path&)): Change first
parameter to _Dir_base&&.
* src/filesystem/dir-common.h (_Dir_base(DIR*)): Remove.
* src/filesystem/dir.cc (_Dir(DIR*, const path&)): Change first
parameter to _Dir_base&&.
The Filesystem TS isn't really supported for Windows, but the FAIL for
this test is just because it doesn't match what happens on Windows.
libstdc++-v3/ChangeLog:
* testsuite/experimental/filesystem/operations/create_directories.cc:
Adjust expected results for Windows.
The recursive_directory_iterator::__erase member was failing for
Windows, because the entry._M_type value is always file_type::none
(because _Dir_base::advance doesn't populate it for Windows) and
top.unlink uses fs::remove which sets an error using the
system_category. That meant that ec.value() was a Windows error code and
not an errno value, so the comparisons to EPERM and EISDIR failed.
Instead of depending on a specific Windows error code for attempting to
remove a directory, just use directory_entry::refresh() to query the
type first. This doesn't avoid the TOCTTOU races with directory
symlinks, but we can't avoid them on Windows without openat and
unlinkat, and creating symlinks requires admin privs on Windows anyway.
This also fixes the fs::remove_all(const path&) overload, which was
supposed to use the same logic as the other overload, but I forgot to
change it before my previous commit.
libstdc++-v3/ChangeLog:
PR libstdc++/104161
* src/c++17/fs_dir.cc (fs::recursive_directory_iterator::__erase):
[i_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Refresh entry._M_type member,
instead of checking for errno values indicating a directory.
* src/c++17/fs_ops.cc (fs::remove_all(const path&)): Use similar
logic to non-throwing overload.
(fs::remove_all(const path&, error_code&)): Add comments.
* src/filesystem/ops-common.h: Likewise.
GCC Administrator
Jonathan Wakely
Detlef Vollmann
Patrick Palka
Rasmus Villemoes
Thomas Rodgers