[Bug c++/94753] -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 --- Comment #4 from Jonathan Wakely --- Maybe I've misunderstood you, but the feature test macros for C++11 features should definitely be defined for C++11. They're not "system-specific" or "GCC-specific". Just because they weren't in the standard prior to C++20 doesn't mean they shouldn't be defined when the corresponding feature is supported.
[Bug libstdc++/114838] __gthread_cond_t et. al. used unconditionally by std_mutex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114838 --- Comment #1 from Jonathan Wakely --- It's guarded with _GLIBCXX_HAS_GTHREADS which is defined by configure when __GTHREADS_CXX0X is defined by , which for gthr-win32.h means: #if _WIN32_WINNT >= 0x0600 #define __GTHREAD_HAS_COND 1 #define __GTHREADS_CXX0X 1 #endif So libstdc++ assumes that __GTHREADS_CXX0X is fixed at build-time, not something that changes from one compilation to the next.
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821 Jonathan Wakely changed: What|Removed |Added Attachment #58015|0 |1 is obsolete|| --- Comment #12 from Jonathan Wakely --- Created attachment 58019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58019=edit Make std::pair relocatable and simplify __relocate_a More comprehensive patch. With this, I see memcpy in the -fdump-tree-optimized dump.
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821 Jonathan Wakely changed: What|Removed |Added Attachment #58014|0 |1 is obsolete|| --- Comment #11 from Jonathan Wakely --- Created attachment 58015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58015=edit Make std::pair relocatable and simplify __relocate_a Fixed patch.
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821 --- Comment #10 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > Created attachment 58014 [details] > Make std::pair relocatable and simplify __relocate_a > > Does this help? Oh hang on, that patch is wrong. I'll fix it and check the results myself ...
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821 --- Comment #7 from Jonathan Wakely --- Created attachment 58014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58014=edit Make std::pair relocatable and simplify __relocate_a Does this help?
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #5 from Jonathan Wakely ---
If the problem is simply that the __restrict qualifiers are not present because
we go through the generic function taking iterators, then we can just add:
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1109,8 +1109,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
_GLIBCXX20_CONSTEXPR
inline __enable_if_t::value, _Tp*>
-__relocate_a_1(_Tp* __first, _Tp* __last,
- _Tp* __result,
+__relocate_a_1(_Tp* __restrict __first, _Tp* __last,
+ _Tp* __restrict __result,
[[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
{
ptrdiff_t __count = __last - __first;
@@ -1147,6 +1147,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::__niter_base(__result), __alloc);
}
+ template
+_GLIBCXX20_CONSTEXPR
+inline _ForwardIterator
+__relocate_a(_Tp* __restrict __first, _Tp* __last,
+_Tp* __restrict __result,
+[[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
+noexcept(std::__is_bitwise_relocatable<_Tp>::value)
+{
+ return std::__relocate_a_1(__first, __last, __result, __alloc);
+}
+
/// @endcond
#endif // C++11
If the problem is that std::pair is not bitwise_relocatable, then we
could change that (as Marc suggested as a possible future enhancement):
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1082,6 +1082,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct __is_bitwise_relocatable
: is_trivial<_Tp> { };
+ template
+struct __is_bitwise_relocatable, void>
+: __and_, is_trivial<_Up>>
+{ };
+
template
_GLIBCXX20_CONSTEXPR
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #4 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> --- a/libstdc++-v3/include/bits/stl_uninitialized.h
> +++ b/libstdc++-v3/include/bits/stl_uninitialized.h
> @@ -1130,7 +1130,58 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> }
>return __result + __count;
> }
> +
> + template
> +_GLIBCXX20_CONSTEXPR
> +inline __enable_if_t::value, _Tp*>
> +__relocate_a(_Tp * __restrict __first, _Tp *__last,
> +_Tp * __restrict __result, _Allocator& __alloc) noexcept
This is wrong, we can't optimize arbitrary allocators, only when the allocator
is std::allocator<_Tp>. That's what the existing code is doing with the
indirection from __relocate_a to __relocate_a_1.
> +{
> + ptrdiff_t __count = __last - __first;
> + if (__count > 0)
> + {
> +#ifdef __cpp_lib_is_constant_evaluated
> + if (std::is_constant_evaluated())
> + {
> + for (; __first != __last; ++__first, (void)++__result)
You don't need the (void) case here because __first and __result are both
pointers. That's only needed for the generic __relocate_a that deals with
arbitrary iterator types.
> + {
> + // manually inline relocate_object_a to not lose restrict
> qualifiers
We don't care about restrict when is_constant_evaluated is true, we're not
optimizing this code. It just gets interpreted at compile time. There is no
reason to inline __relocate_object_a for the is_constant_evaluated case.
> + typedef std::allocator_traits<_Allocator> __traits;
> + __traits::construct(__alloc, __result,
> std::move(*__first));
> + __traits::destroy(__alloc, std::__addressof(*__first));
> + }
> + return __result;
> + }
> #endif
> + __builtin_memcpy(__result, __first, __count * sizeof(_Tp));
> + }
> + return __result + __count;
> +}
> +#endif
> +
> + template
> +_GLIBCXX20_CONSTEXPR
> +#if _GLIBCXX_HOSTED
> +inline __enable_if_t::value, _Tp*>
> +#else
> +inline _Tp *
> +#endif
> +__relocate_a(_Tp * __restrict __first, _Tp *__last,
> +_Tp * __restrict __result, _Allocator& __alloc)
> +noexcept(noexcept(std::allocator_traits<_Allocator>::construct(__alloc,
> +__result, std::move(*__first)))
> +&& noexcept(std::allocator_traits<_Allocator>::destroy(
> + __alloc, std::__addressof(*__first
> +{
> + for (; __first != __last; ++__first, (void)++__result)
> + {
> + // manually inline relocate_object_a to not lose restrict
> qualifiers
> + typedef std::allocator_traits<_Allocator> __traits;
> + __traits::construct(__alloc, __result, std::move(*__first));
> + __traits::destroy(__alloc, std::__addressof(*__first));
> + }
I don't understand this overload at all. Is this overload the one that actually
gets used for your testcase? I think it should be, because std::pair
is not bitwise_relocatable.
Why does the restrict qualifier get lost if we don't inline relocate_object_a?
That function is restrict-qualified as well.
> + return __result;
> +}
>
>template typename _Allocator>
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821 --- Comment #3 from Jonathan Wakely --- (In reply to Jan Hubicka from comment #2) > This seems to do the trick, but for some reason I get memmove What's the second overload for, and why does it depend on _GLIBCXX_HOSTED?
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #1 from Jonathan Wakely ---
Using memcpy on any std::pair is undefined behaviour because it's not trivially
copyable.
That's not because it has a copy constructor, its copy constructor is defaulted
and so trivial if the data members are trivially copy constructible:
constexpr pair(const pair&) = default;///< Copy constructor
It's because it has a non-trivial assignment operator:
/// Copy assignment operator
constexpr pair&
operator=(const pair& __p)
noexcept(_S_nothrow_assignable())
requires (_S_assignable())
{
first = __p.first;
second = __p.second;
return *this;
}
I think this exact point was discussed when Marc introduced the relocate
optimizations. We could maybe cheat and say that we know it's safe to memcpy
std::pair even though the language says it's undefined, because we
know what our std::pair implementation looks like.
[Bug c++/99934] bad_array_new_length thrown when non-throwing allocation function would have been used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99934 Jonathan Wakely changed: What|Removed |Added CC||pshevchuk at pshevchuk dot com --- Comment #5 from Jonathan Wakely --- *** Bug 114806 has been marked as a duplicate of this bug. ***
[Bug c++/114806] placement new doesn't check array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114806 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 99934 ***
[Bug c++/114806] placement new doesn't check array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114806 --- Comment #1 from Jonathan Wakely --- *** Bug 114805 has been marked as a duplicate of this bug. ***
[Bug c++/114805] placement new doesn't check array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114805 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 114806 ***
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #10 from Jonathan Wakely --- N.B. If you're going to do any more profiling + optimizing of std::vector, please do it with -std=gnu++20 so that everything is constexpr. Otherwise you're only testing C++17 which is the last version before everything in std::vector becomes constexpr. For the later standards the optimizations will probably behave very differently.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #9 from Jonathan Wakely --- Another solution is just to use __builtin_expect or [[likely]] or [[unlikely]] at the call site. That wouldn't need any compiler changes.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #7 from Jonathan Wakely --- I think we might want to add __attribute__((cold)) to std::vector functions that are now implicitly inline due to the addition of `constexpr`. We probably don't want to use noinline as that's too strong.
[Bug libstdc++/114770] std::chrono::locate_zone("Asia/Chungking") fails on Debian Sid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-04-18 Target Milestone|--- |13.3
[Bug libstdc++/114770] New: std::chrono::locate_zone("Asia/Chungking") fails on Debian Sid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
Bug ID: 114770
Summary: std::chrono::locate_zone("Asia/Chungking") fails on
Debian Sid
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
(void) std::chrono::locate_zone("Asia/Chungking");
}
With the latest tzdata (version 2024a-2) on Debian Sid this fails:
terminate called after throwing an instance of 'std::runtime_error'
what(): tzdb: cannot locate zone: Asia/Chungking
Aborted (core dumped)
The problem is a Debian patch that enables link chaining, so that one link can
have another link as its target:
https://sources.debian.org/patches/tzdata/2024a-2/ziguard.awk-Move-link-to-link-feature-from-vanguard-to-ma.patch/
This feature was added to tzdata in 2022, but isn't compatible with the
expectations of the C++20 standard. When chrono::locate_zone finds a link, it
expects its target to be a zone, not another link.
[Bug tree-optimization/114758] The layout of a std::vector reports a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758 --- Comment #2 from Jonathan Wakely --- It's just yet another occurrence of false positive -Wstringop-overflow warnings, it has nothing to do with vector being special.
[Bug c++/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> With __val = 9223372036854775808LL __sign = -1LL
Oops, that should be __val = 9223372036854775808ULL and __sign = -1
i.e.
int main()
{
unsigned long long val = 9223372036854775808ULL;
int sign = -1;
long long res;
return __builtin_mul_overflow(val, sign, );
}
This shouldn't trap.
[Bug c++/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-17 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- The abort happens here: if (__builtin_mul_overflow(__val, __sign, &__tmp)) With __val = 9223372036854775808LL __sign = -1LL The libgcc2.c:__mulvdi3 function reaches the abort() on line 375
[Bug libstdc++/57585] New --enable-clocale model using POSIX 2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585 --- Comment #4 from Jonathan Wakely --- Created attachment 57961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57961=edit Add --enable-clocale=ieee_1003.1-2008 This is an initial prototype of a new clocale model. The wide string info needs to be transcoded from the narrow string info, because unlike Glibc, POSIX doesn't provide wide character versions of nl_langinfo items like _NL_WMON_1
[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050 --- Comment #13 from Jonathan Wakely --- -fexcess-precision does affect constants. With -fexcess-precision=standard, assignments and casts discard excess precision which may otherwise be present in arithmetic expressions and constants. With -fexcess-precision=fast the excess precision might be retained even after casts and assignments, or it might be discarded at other points. But in both cases, a floating constant might have excess precision. Whether that excess precision is discarded, and when it's discarded, is affected by -fexcess-precision.
[Bug libstdc++/114742] invalid use of '__ieee128' in and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742 --- Comment #2 from Jonathan Wakely --- Mathias noted that still fails with -mcpu=power7 Checking for _ARCH_PWR8 or __POWER8_VECTOR__ instead works.
[Bug libstdc++/114742] invalid use of '__ieee128' in and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-16 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I think we need something like this in #ifndef __VSX__ # undef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT #endif Otherwise we might set the ALT128_COMPAT macro during configure, but then it becomes invalidated during compilation of user code if they "downgrade" to something that doesn't support ieee128, using -mcpu=power6 and/or -mlong-double-64
[Bug libstdc++/57585] New --enable-clocale model using POSIX 2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Separately, it would be good to provide a libintl-based implementation of > std::messages, for targets where that's not part of glibc. Although the POSIX catopen/catclose/catgets one might be good enough, once we support https://cplusplus.github.io/LWG/lwg-defects.html#2028 so that messages_base::catalog is large enough to store a nl_catd.
[Bug c++/114740] i686-linux-gnu-g++ does not interpret floating point literals as double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740 --- Comment #1 from Jonathan Wakely --- See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx
[Bug libstdc++/41495] libstdc++ --enable-clocale=ieee_1003.1-2001 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > N.B. messages_base::catalog is required to be a typedef for int, although > there is an open issue which would allow intptr_t to be used instead: > http://open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#2028 That was resolved to make it an unspecified integer type: https://cplusplus.github.io/LWG/lwg-defects.html#2028
[Bug libstdc++/57585] New --enable-clocale model using POSIX 2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585 --- Comment #2 from Jonathan Wakely --- Separately, it would be good to provide a libintl-based implementation of std::messages, for targets where that's not part of glibc.
[Bug libstdc++/106749] Implement C++23 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 Bug 106749 depends on bug 113386, which changed state. Bug 113386 Summary: [C++23] std::pair comparison operators should be transparent, but are not in libstdc++ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Done for gcc 14.
[Bug libstdc++/93672] [11/12/13 Regression] std::basic_istream::ignore hangs if delim MSB is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672 Jonathan Wakely changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |std::basic_istream::ignore |std::basic_istream::ignore |hangs if delim MSB is set |hangs if delim MSB is set --- Comment #6 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/114721] libstdc++-v3/include/ext/codecvt_specializations.h: 2 * small performance tweeks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114721 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-04-15 Ever confirmed|0 |1 Severity|normal |trivial Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I don't think anybody uses this extension either, but the change seems worth doing.
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jonathan Wakely --- Fixed
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 --- Comment #9 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 --- Comment #6 from Jonathan Wakely --- r14-739-gc62e945492afbb incorrectly added them to GLIBCXX_3.4.32 which should have been frozen after 13.1 but it looks like I thought it was a new version for 13.2/14.0 Then I must have thought 13.2 and 14.0 were both using that new version, they should both have those new symbols.
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 --- Comment #5 from Jonathan Wakely --- The *shouldn't* have been added there though.
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 --- Comment #4 from Jonathan Wakely --- This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
GLIBCXX_3.4.32 {
_ZSt21ios_base_library_initv;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
+} GLIBCXX_3.4.31;
+
+GLIBCXX_3.4.33 {
# std::basic_file<>::native_handle()
_ZNKSt12__basic_fileI[cw]E13native_handleEv;
-} GLIBCXX_3.4.31;
+} GLIBCXX_3.4.32;
# Symbols in the support library (libsupc++) have their own tag.
CXXABI_1.3 {
[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-04-11 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624 --- Comment #6 from Jonathan Wakely --- It's also a mostly-harmless ABI change for C++17 down, because the underlying type without -fshort-enums changes from implicitly being chosen as unsigned int, to explicitly being specified as int.
[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #5 from Jonathan Wakely ---
I think we should just do this:
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline constexpr memory_order memory_order_acq_rel = memory_order::acq_rel;
inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cst;
#else
- typedef enum memory_order
+ enum memory_order : int
{
memory_order_relaxed,
memory_order_consume,
@@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order_release,
memory_order_acq_rel,
memory_order_seq_cst
-} memory_order;
+};
#endif
/// @cond undocumented
That ensures a consistent underlying type for C++17 down and C++20 up (and gets
rid of the redundant typedef). This will mean the type isn't affected by the
-fshort-enums flag at all, which also happens to solve the static_assert
failure in comment 0.
This is an ABI change for the underlying type when using -fshort-enums, but
that flag is already explicitly ABI-changing and not the default, so I care
less about a change there.
[Bug libstdc++/114680] libstdc++-v3/include/ext/mt_allocator.h:142: possible performance problem ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #2 from Jonathan Wakely ---
There's line 685 too
void
_M_set_options(__pool_base::_Tune __t)
{ __policy_type::_S_get_pool()._M_set_options(__t); }
[Bug libstdc++/114680] libstdc++-v3/include/ext/mt_allocator.h:142: possible performance problem ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680 --- Comment #1 from Jonathan Wakely --- I doubt anybody uses that code anyway.
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 --- Comment #8 from Jonathan Wakely --- Thanks. I hope we'll end up auto-generating a file like that from ../gcc/cp/cxxapi-data.csv
[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989 --- Comment #24 from Jonathan Wakely --- > * testsuite/30_threads/jthread/95989.cc: New test. This testcase fails on FreeBSD 14: Starting program: /home/gcc/build/x86_64-unknown-freebsd14.0/libstdc++-v3/testsuite/95989.exe [New LWP 106082 of process 5331] Thread 2 received signal SIGABRT, Aborted. Sent by thr_kill() from pid 5331 and user 1001. [Switching to LWP 106082 of process 5331] thr_kill () at thr_kill.S:4 warning: 4 thr_kill.S: No such file or directory (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x0042803f in __raise (s=s@entry=6) at /usr/src/lib/libc/gen/raise.c:50 #2 0x0043c779 in abort () at /usr/src/lib/libc/stdlib/abort.c:64 #3 0x00400cbc in uw_init_context_1 (context=context@entry=0x7fffdfffdd50, outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x425546 ) at /mnt/gcc-src/libgcc/unwind-dw2.c:1336 #4 0x004146a6 in _Unwind_ForcedUnwind (exc=0x80082d940, stop=0x4256f0 , stop_argument=stop_argument@entry=0x0) at /mnt/gcc-src/libgcc/unwind.inc:212 #5 0x00425546 in thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172 #6 0x004254af in _pthread_exit_mask (status=0x0, mask=mask@entry=0x0) at /usr/src/lib/libthr/thread/thr_exit.c:254 #7 0x0042541b in _Tthr_exit (status=0x19e62) at /usr/src/lib/libthr/thread/thr_exit.c:206 #8 0x00424f2d in thread_start (curthread=0x80082d700) at /usr/src/lib/libthr/thread/thr_create.c:289 #9 0x in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 (gdb) fr 3 #3 0x00400cbc in uw_init_context_1 (context=context@entry=0x7fffdfffdd50, outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x425546 ) at /mnt/gcc-src/libgcc/unwind-dw2.c:1336 1336 gcc_assert (code == _URC_NO_REASON);
[Bug c++/114675] warning for "reference to not fully constructed object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675 --- Comment #3 from Jonathan Wakely --- Yeah I looked for a dup too, as I'm sure this has been reported before.
[Bug target/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #13 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #11) > *** Bug 112745 has been marked as a duplicate of this bug. *** And as suggested in Bug 112745, either lld should Just Work or GCC should work around whatever weirdness means it can't find libc. (In reply to Andrew Pinski from comment #12) > I think this is related to PR 104707 . Aha, maybe - I was using --disable-multilib It doesn't look like Rainer was though.
[Bug c++/114675] warning for "reference to not fully constructed object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
--- Comment #1 from Jonathan Wakely ---
A complete testcase that actually compiles:
struct A { };
struct C { C(const A&); };
struct B { B(const C&); };
struct everything {
everything() : a(), b(c), c(a) { }
A a;
B b;
C c;
};
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #10 from Jonathan Wakely --- If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then it needs to be documented at https://gcc.gnu.org/install/specific.html#x-x-freebsd
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-10 --- Comment #9 from Jonathan Wakely --- ld: error: unable to find library -lc collect2: error: ld returned 1 exit status gmake[1]: *** [Makefile:1005: libgcc_s.so] Error 1 gmake[1]: Leaving directory '/home/gcc/build/x86_64-unknown-freebsd14.0/libgcc'
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #23 from Jonathan Wakely --- Re https://github.com/cplusplus/draft/issues/6922 It can't possibly mean that the returned time zone *needs* to be the same as the C library, because that's impossible in general, because the C library isn't required to use IANA zones at all. See my TZ=garbage23nonsense example. There is no way to match that with std::chrono::time_zone without pointer lifetime issues and inconsistencies like returning a time_zone that isn't in the tzdb. And if the C++ standard intended to require that TZ is respected on POSIX systems, then it would say so. The absence of any requirement means it's not required. TZ is not mentioned in the standard at all. The standard probably isn't going to say it *must not* be used, because it's not in the business of listing (or forbidding) possible vendor extensions. There might be systems where a TZ environment var is the only way the time zone can be set, and it always is an IANA zone. But I don't believe any of the targets libstdc++ supports fit into that category.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #22 from Jonathan Wakely --- I do still consider it incorrect. But what I mean re libc++ is that *even ignoring* the general problems with using TZ, *their implementation* of using TZ isn't even correct. If the intention is to follow POSIX, it fails to do that.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #20 from Jonathan Wakely --- (In reply to Harald van Dijk from comment #18) > (In reply to Jonathan Wakely from comment #16) > > ... incorrectly though? > > Given that you have expressed your view that *any* attempt at using TZ is > inherently incorrect, I am not surprised that you view libc++'s attempt as > incorrect. :) That's not what I mean. I do consider it ill-advised and unsafe to use TZ (since getenv can introduce data races, and I don't think they document potentially concurrent calls to current_zone() and setenv as being unsafe), but libc++ is free to define current_zone() that way if they think that is right for their users. The comment in libc++ notes other problems like the lifetime and ownership one I noted in comment 8, and the inconsistency between "MST" being recognized as an IANA zone but "MST-3" not being. They say "the documentation is unclear" but I disagree, "MST-3" is perfectly valid according to POSIX. And so is TZ="garbage23nonsense", because there is no requirement in POSIX for POSIX-style time zone definitions to have any relation to a real IANA zone. The std and dst names in a POSIX zone are effectively arbitrary. Glibc gets this right: $ date Wed 10 Apr 01:04:17 BST 2024 $ TZ=garbage23nonsense date Tue 9 Apr 02:04:18 nonsense 2024 But quite aside from that, my point in comment 16 is that if they're going to use TZ, I would expect TZ=":Europe/London" to work.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #19 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #16) > I would expect TZ=:Europe/London to work according to POSIX, Well, POSIX says ":characters" is implementation-defined, but for Glibc it looks up an IANA zone. I would also expect "7" to work, since the current POSIX spec describes that.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #17 from Jonathan Wakely --- And "Factory" isn't a valid POSIX zone, so remove that one from the list. So if I'm reading it correctly, some European zones and the US zones can be used in $TZ with libc++ but most IANA zones won't work. And then it just silently ignores $TZ and falls back to /etc/localtime so an application still can't actually rely on $TZ being used. It might work, for a small set of zones, or it might not work.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #16 from Jonathan Wakely --- (In reply to Harald van Dijk from comment #14) > (In reply to Jonathan Wakely from comment #8) > > None of libstdc++, LLVM libc++, MSVC STL or the > > date/tz.h reference implementation uses $TZ for chrono::current_zone, > > This does not appear to be accurate. > > libc++ appears to always uses $TZ on POSIX-like platforms if it is set: > https://github.com/llvm/llvm-project/blob/ > 788be0d9fc6aeca548c90bac5ebe6990dd3c66ec/libcxx/src/tzdb.cpp#L708 ... incorrectly though? I would expect TZ=:Europe/London to work according to POSIX, but it seems they don't remove the ':' before the lookup. So it only works for a string like "MST7MDT" which means only the following entries in the IANA database can be matched by a value in $TZ: Z CET 1 c CE%sT Z CST6CDT -6 u C%sT Z EET 2 E EE%sT Z EST -5 - EST Z EST5EDT -5 u E%sT Z Factory 0 - -00 Z HST -10 - HST Z MET 1 c ME%sT Z MST -7 - MST Z MST7MDT -7 u M%sT Z PST8PDT -8 u P%sT Z WET 0 E WE%sT That doesn't seem very well thought out or tested.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #15 from Jonathan Wakely --- (In reply to Hristo Venev from comment #13) > > $TZ allows you to override it per-process (and even change it during the > > lifetime of a process by using setenv and tzset). We don't support that for > > current_zone(). > > /etc/localtime can also change. But not in a racy way. The filesystem serializes those changes so that inspecting the symlink with readlink(3) gives a single race-free answer at any one time. And if the application wants to query current_zone() once and then reuse the result of that query, it can, because the time_zone* is a value held by the application itself. That's an advantage of the std::chrono design which is absent from libc, where the application has very little control over the hidden state that libc maintains for time zone info. > > The intent is to infer an IANA time zone from the /etc/localtime symlink, > > if possible. If the intent was to match libc, it would look at $TZ. I've > > discussed this exact question with the author of that library (which is the > > origin of the std::chrono components too). What I said in comment 8 above > > is paraphrasing what he said. > > Point taken. Still, do you have any explanation for why this behavior was > chosen? Because the environment cannot be accessed safely, and because $TZ was traditionally used for POSIX time zones, which are inferior to the IANA zones in nearly every way (see the "POSIX style time zones" section of https://stackoverflow.com/tags/timezone/info for more details). > > Just do the easy thing yourself. > > The easy thing being to fix all applications that currently use or will ever > use current_zone(). Fun times ahead... Well they should not be assuming current_zone() uses $TZ in the first place - that has never been claimed or documented by any reputable source. You only need to "fix" the ones that were relying on something that was never part of the API.
[Bug libstdc++/114633] [14 Regression] A cross to rx fails to build in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Thanks for testing it, so this should be fixed now.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #12 from Jonathan Wakely --- (In reply to Hristo Venev from comment #9) > I stumbled upon this comment in the library you linked: > > https://github.com/HowardHinnant/date/blob/ > 0e65940a7fbc4ed617a1ee111a60311eccbead9a/include/date/tz.h#L35 > > That comment is wrong in its explanation of the mechanism used to determine > the local time zone on Linux. However, it clearly shows that the intent is > to match the platform's "local time" as closely as reasonably possible. The intent is for current_zone() to be "the time zone which the computer has set as its local time zone", not the time zone that _the process_ has set via TZ. That's /etc/localtime on GNU/Linux and many unixes. Which is what the comment says. $TZ allows you to override it per-process (and even change it during the lifetime of a process by using setenv and tzset). We don't support that for current_zone(). > The implementation also has some comments: > > https://github.com/HowardHinnant/date/blob/ > 0e65940a7fbc4ed617a1ee111a60311eccbead9a/src/tz.cpp#L3936 > > The intent seems to be clear -- apply a lot of heuristics to try to match > what libc would do as closely as possible. The intent is to infer an IANA time zone from the /etc/localtime symlink, if possible. If the intent was to match libc, it would look at $TZ. I've discussed this exact question with the author of that library (which is the origin of the std::chrono components too). What I said in comment 8 above is paraphrasing what he said. > Even on Linux there are no guarantees whatsoever that it is possible to > extract a IANA time zone from /etc/localtime. And so current_zone() can fail. > In fact, the problem is > exactly identical to that with $TZ, if not worse -- $TZ is normally an IANA > time zone name, whereas /etc/localtime is a symlink (but sometimes a > hardlink or a copy) of a file in some OS-specific directory (sometimes, but > not always, /usr/share/zoneinfo) where the name of the file relative to the > base directory is a IANA time zone name. If $TZ is an IANA name then you can just look that name up with locate_zone, it's easy. If $TZ is a POSIX time zone spec, things are more complicated. So the most we could do is handle the easy case, but not in a thread-safe way (because the environment is mutable and not synchronized). So we could support something that is already easy for users to do, by introducing possible data races into the program. That doesn't seem like a good trade off to me. Just do the easy thing yourself.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #8 from Jonathan Wakely ---
Yes, if an application assumes that chrono::current_zone matches $TZ, that's a
bug in the application. None of libstdc++, LLVM libc++, MSVC STL or the
date/tz.h reference implementation uses $TZ for chrono::current_zone, and I
don't see how we could do so without breaking the guarantee that
locate_zone(current_zone()->name()) works. The lifetime and ownership of the
pointer returned by current_zone would also be unclear if it didn't return one
of the IANA zones owned by a tzdb object.
The C++ library is extensible outside of namespace std, for example:
https://github.com/HowardHinnant/date/blob/master/include/date/ptz.h
(that uses the types and constants from the date namespace defined in date/tz.h
but that can be replaced by namespace date { using namespace std::chrono; })
We could provide something similar as an extension, but it wouldn't be used
automatically by chrono::current_zone, because POSIX time zones (as used by
libc) are not IANA zones.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jonathan Wakely --- (In reply to Hristo Venev from comment #4) > Therefore current_zone() as currently implemented is worse than useless -- > it is a footgun. So don't use it then. > The people who wrote the standard probably did not consider how various > platforms handle default time zones this at all. That's a pretty bug assumption, and wrong. > I don't understand why you consider the ability to override the default time > zone using an environment variable to be a flaw. For one, the environment is mutable and not threadsafe. Anyway, this isn't going to change just because you don't like it.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #5 from Jonathan Wakely --- The libc time zone doesn't necessarily correspond to anything in the IANA database anyway. If you use a POSIX time zone definition like TZ="abc4abd" then libc will use that to generate a custom time zone and use that for localtime, ctime etc. That's not compatible with the std::chrono model, which uses the IANA zones. So "the time zone libc would consider local" might not be a real time zone anyway. If you want to interpret $TZ then you can write code to do so, and convert that into a name that std::chrono::locale_zone understands. So if TZ is an IANA name, use it directly, otherwise extract the offset part and then use something like "Etc/GMT-8".
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #3 from Jonathan Wakely --- What does "quite a bit completely useless" mean? current_zone() tells you what /etc/localtime is set to. So it's as useless as /etc/localtime, no more and no less. Did you read the messages I linked to?
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #1 from Jonathan Wakely --- Ignoring $TZ is a feature, not a bug. See https://gcc.gnu.org/pipermail/libstdc++/2023-May/055928.html and the replies, including https://gcc.gnu.org/pipermail/libstdc++/2023-May/055933.html
[Bug target/114615] spurious warning on mingw-w64: 'memcpy' reading 4 or more bytes from a region of size 2 with std::wstring{L""} and -flto -O1 [Wstringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615 --- Comment #3 from Jonathan Wakely --- The dumb part is that __n here comes from wcslen(__s2), so the compiler is able to track that __s2 is only two bytes, but not capable of tracking that __n == 0. Specifically, __n is (__s2 + wcslen(__s2)) - __s2 which is just wcslen(L"") which is 0.
[Bug target/114615] spurious warning on mingw-w64: 'memcpy' reading 4 or more bytes from a region of size 2 with std::wstring{L""} and -flto -O1 [Wstringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Jonathan Wakely ---
Or jump threading is splitting the code into two branches for N <= 1 and N >=
2, and then warning that the N >= 2 case would read past the end of the source
buffer. But that case never actually happens.
The constructor calls _M_construct which goes to:
static void
_S_copy(_CharT* __d, const _CharT* __s, size_type __n)
{
if (__n == 1)
traits_type::assign(*__d, *__s);
else
traits_type::copy(__d, __s, __n);
}
The N == 1 case is handled here, then char_traits::copy does:
static _GLIBCXX20_CONSTEXPR char_type*
copy(char_type* __s1, const char_type* __s2, size_t __n)
{
if (__n == 0)
return __s1;
#if __cplusplus >= 202002L
if (std::__is_constant_evaluated())
return __gnu_cxx::char_traits::copy(__s1, __s2, __n);
#endif
return wmemcpy(__s1, __s2, __n);
}
So the N == 0 case is also handled here, so we only use wmemcpy for N >= 2. And
that would indeed read N * sizeof(wchar_t), i.e. 4 or more bytes, from L""
which is only 2 bytes.
But it's unreachable, because we take the if (__n == 0) branch.
[Bug libstdc++/114633] [14 Regression] A cross to rx fails to build in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2024-04-08
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -3685,6 +3685,7 @@ namespace __detail
if (!__is_failed(__err)) [[likely]]
{
long double __val{};
+#if __cpp_lib_to_chars
string __str = std::move(__buf).str();
auto __first = __str.data();
auto __last = __first + __str.size();
@@ -3694,6 +3695,9 @@ namespace __detail
if ((bool)ec || ptr != __last) [[unlikely]]
__err |= ios_base::failbit;
else
+#else
+ if (__buf >> __val)
+#endif
{
duration __fs(__val);
if constexpr (__is_floating)
[Bug c++/53341] overloaded operator delete(void *) appear in object file even when not directly used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341 --- Comment #3 from Jonathan Wakely --- Bisections indicates it was fixed by this commit: commit ead84f73b0a0f39ea39aa0329b6da83e4a9e6e02 [r0-116315-gead84f73b0a0f3] Author: Jan Hubicka Date: Fri Apr 20 15:09:11 2012 lto-symtab.c (lto_cgraph_replace_node): Merge needed instead of force flags. * lto-symtab.c (lto_cgraph_replace_node): Merge needed instead of force flags. * cgraph.c (cgraph_add_thunk): Use mark_reachable_node. (cgraph_remove_node): Update. (cgraph_mark_needed_node): Remove. (cgraph_mark_force_output_node): New. (dump_cgraph_node): Do not dump needed flag. (cgraph_node_cannot_be_local_p_1): Update. (cgraph_can_remove_if_no_direct_calls_and_refs): Update. * cgraph.h (symtab_node_base): Add force_output flag. (cgraph_node): Remove needed flag. (varpool_node): Remove force_output flag. (cgraph_mark_needed_node): Remove. (cgraph_mark_force_output_node): New. (cgraph_only_called_directly_or_aliased_p, varpool_can_remove_if_no_refs, varpool_all_refs_explicit_p): Update. * ipa-cp.c (ipcp_generate_summary): Remove out of date assert. * cgraphunit.c (cgraph_decide_is_function_needed): rewrite. (cgraph_add_new_function); Update. (cgraph_mark_if_needed); Update. (verify_cgraph_node): Update. (cgraph_analyze_function): Alias target is reachable. (process_function_and_variable_attributes): Update: externally_visible flag makes function reachable. (cgraph_analyze_functions): Update dumping. * lto-cgraph.c (lto_output_node, lto_output_varpool_node, input_overwrite_node, input_varpool_node): Update streaming. * lto-streamer-out.c (produce_symtab): Use force_output. * ipa.c (process_references): Weakrefs must be processed. (cgraph_remove_unreachable_nodes): Likewise; update for new force_output flag. (varpool_externally_visible_p); Weakrefs are externally visible even if they are not. (function_and_variable_visibility): Update; when processing alias pair force the targets to be output. (whole_program_function_and_variable_visility): Use mark_reachable_node. * trans-mem.c (ipa_tm_mark_needed_node): Remove (ipa_tm_mark_force_output_node): New function. (ipa_tm_create_version_alias, ipa_tm_create_version): Update. * gimple-fold.c (can_refer_decl_in_current_unit_p): Be lax about aliases. * varasm.c (mark_decl_referenced): Update. (find_decl_and_mark_needed): Remove. (find_decl): New function. (weak_finish, finish_aliases_1, assemble_alias): Update; do not mark alias targets as needed. (dump_tm_clone_pairs): Update. * tree-inline.c (copy_bb): Update check. * symtab.c (dump_symtab_base): Dump force_output. * tree-ssa-structalias.c (ipa_pta_execute): Use force_output. * passes.c (execute_todo): Fix dumping. * varpool.c (decide_is_variable_needed, varpool_finalize_decl): Update. (varpool_analyze_pending_decls): Alias target is reachable. (varpool_create_variable_alias): Finalize weakrefs. * class.c (make_local_function_alias): Do not mark symbol referenced. * objc-acct.c (mark_referenced_methods); Use cgraph_mark_force_output_node. * gcc-interface/utils.c (gnat_write_global_declarations): Update for new force_output placement. * lto/lto-partition.c (partition_cgraph_node_p): Use force_output. From-SVN: r186624
[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 --- Comment #16 from Jonathan Wakely --- It's a shame the fix happened after the inferior shared_ptr implementation was frozen into libstdc++ though :-(
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196 Jonathan Wakely changed: What|Removed |Added CC||zwuis at outlook dot com --- Comment #18 from Jonathan Wakely --- *** Bug 114602 has been marked as a duplicate of this bug. ***
[Bug libstdc++/114602] Compilcation failure when using a user-defined function which name is same as a posix function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114602
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Jonathan Wakely ---
This is a longstanding issue that glibc headers expose all APIs when included
from C++ code.
You can either cast the function pointer to the right type:
std::sort(ptr, ptr, static_cast(bcmp));
or use a lambda expression:
std::sort(ptr, ptr, [](foo l, foo r) { return bcmp(l, r); });
*** This bug has been marked as a duplicate of bug 11196 ***
[Bug c++/114585] Incorrect boolean value with O2/O3 optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585 --- Comment #2 from Jonathan Wakely --- The bug reporting guidelines you were asked to read say to try -fsanitize=undefined and if you'd done that you'd have seen errors: https://godbolt.org/z/bscj8q9rr
[Bug libstdc++/93672] [11/12/13/14 Regression] std::basic_istream::ignore hangs if delim MSB is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672 Jonathan Wakely changed: What|Removed |Added Summary|std::basic_istream::ignore |[11/12/13/14 Regression] |hangs if delim MSB is set |std::basic_istream::ignore ||hangs if delim MSB is set Known to fail||11.4.0, 12.3.0, 13.2.0, ||14.0, 4.0.0, 9.1.0 Known to work||3.4.6 Target Milestone|--- |11.5 --- Comment #4 from Jonathan Wakely --- The incorrect behaviour was introduced with r0-59139-g80dddedcaf316e
[Bug libstdc++/93672] std::basic_istream::ignore hangs if delim MSB is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #3 from Jonathan Wakely ---
So maybe:
--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -112,7 +112,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
basic_istream::
ignore(streamsize __n, int_type __delim)
{
- if (traits_type::eq_int_type(__delim, traits_type::eof()))
+ // If __delim is eof() we ignore up to __n chars, and for any other
+ // negative value using eq_int_type(sgetc(), __delim) will never be
true,
+ // so just treat all negative __delim values as eof().
+ if (__delim < 0)
return ignore(__n);
_M_gcount = 0;
[Bug libstdc++/93672] std::basic_istream::ignore hangs if delim MSB is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672 --- Comment #2 from Jonathan Wakely --- On second thoughts, I don't think that fix is right. istream::ignore takes an int_type for the delimiter, so passing it a char_type with a negative value will confuse it. For example, str.ignore(n, '\xff`) will treat the delimiter as EOF and ignore up to n chars, ignoring any '\xff` characters that might be in the stream buffer's get area. That means it's wrong to call ignore(n, '\xff') on a platform where char is signed, because it won't do what you expect (unless you're really intending to treat \xff as EOF). This case is similar, it ignores up to n characters, or until sgetc() returns a character equal to '\x80' ... but that can never happen because sgetc() never returns a negative value unless it reaches EOF. So there is a gcc bug here, because we should not loop forever. But the problem is that we use inconsistent conditions for deciding whether we've found the delimiter.
[Bug libstdc++/93672] std::basic_istream::ignore hangs if delim MSB is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2024-04-03 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Looks like I missed this one when it was filed. The fix is: --- a/libstdc++-v3/src/c++98/istream.cc +++ b/libstdc++-v3/src/c++98/istream.cc @@ -126,6 +126,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION const int_type __eof = traits_type::eof(); __streambuf_type* __sb = this->rdbuf(); int_type __c = __sb->sgetc(); + __delim = traits_type::to_int_type(__cdelim); bool __large_ignore = false; while (true)
[Bug libstdc++/88607] forward_list.h contains utf-8 charactor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88607 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- This was fixed for gcc 9.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #8 from Jonathan Wakely --- (In reply to Iain Sandoe from comment #7) > So I am actually asking > - if the extension actually has any useful meaning? For non-darwin, yes, it requests the storage of two initializer lists to be merged (see the commit msg for r14-1500-g4d935f52b0d5c0). > - if it is an extension it probably should be only available in gnu:: ? It's a standard attribute. The extension is allowing it to be placed on variables that aren't non-static data members. If you spell it gnu::no_unique_address then it's a completely different attribute (and in that case I'd suggest an alternative name, because we don't want to recreate the msvc::no_unique_address debacle, or even give the impression of doing so!)
[Bug libstdc++/114519] [14 Regression] GCC 14 trunk fails to compile chrono with -fno-char8_t -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||13.2.0 Known to fail||14.0 Summary|GCC 14 trunk fails to |[14 Regression] GCC 14 |compile chrono with |trunk fails to compile |-fno-char8_t -std=gnu++20 |chrono with -fno-char8_t ||-std=gnu++20 --- Comment #4 from Jonathan Wakely --- Fixed, thanks for the report.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #6 from Jonathan Wakely --- Yes, I think it's an extension, added by r14-1500-g4d935f52b0d5c0 The question then is whether the attribute is supposed to be a non-binding request or not. If it's a non-binding request then the test should be adjusted/unsupported for this target. If the latter, then that use of the attribute should be ill-formed for this target and give an error.
[Bug libstdc++/114553] Undefined symbol in directory_iterator move assignment operator with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553 --- Comment #2 from Jonathan Wakely --- (In reply to Toni Lammi from comment #0) > The issue does not seem to be present in trunk. It seems to be a change in inlining decisions on trunk, because the swap symbol still isn't exported from the shared lib. So the problem is probably latent on trunk.
[Bug libstdc++/114553] Undefined symbol in directory_iterator move assignment operator with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-02 Ever confirmed|0 |1
[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Further reduced:
Actually now that it's no longer a function template we don't even need to
instantiate it to trigger the error, so this is the minimal reproducer:
void create(void* u) {
const void* const& r = ( (void)0, u );
}
[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #3 from Jonathan Wakely ---
Further reduced:
void create(void* u) {
const void* const& r = ( (void)0, u );
}
void test_func() {
create(0);
}
The result of (0, u) is an lvalue of type void* which should then be converted
to a const void* prvalue, which is then bound to the reference.
[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #2 from Jonathan Wakely ---
Reduced:
void* const NONE = nullptr; //Compiles
void beforeParam();
template
void create(U && u) noexcept {
const void* const& r = ( (void) beforeParam(), u );
}
void test_func() {
create(NONE);
}
comma.cc: In instantiation of ‘void create(U&&) [with U = void* const&]’:
comma.cc:11:11: required from here
comma.cc:7:24: error: lvalue required as unary ‘&’ operand
7 | const void* const& r = ( (void) beforeParam(), u );
|^
GCC has recurring problems with parentheses causing lvalue expressions to be
incorrectly treated as rvalues.
[Bug c++/57573] [C++1y] bogus "taking address of temporary" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57573 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60409 Known to work|4.10.0 |5.0 --- Comment #6 from Jonathan Wakely --- For the record, it started to fail with: commit 10c6dc8e3932d33c8e47e6706885d2412b29c069 [r0-122521-g10c6dc8e3932d3] Author: Jason Merrill Date: Fri Mar 29 19:51:36 2013 cp-tree.h (AUTO_IS_DECLTYPE): New. N3582 * cp-tree.h (AUTO_IS_DECLTYPE): New. * parser.c (cp_parser_decltype): Handle decltype(auto). (cp_parser_type_id_1): Allow auto without a late-specified return in C++1y. (cp_parser_primary_expression): Use the return value of finish_parenthesized_expr. (cp_parser_transaction_expression): Likewise. * semantics.c (force_paren_expr): New. (finish_parenthesized_expr): Use it. * call.c (build_conditional_expr_1): Likewise. * pt.c (do_auto_deduction): Handle decltype(auto). (tsubst_copy): Handle PAREN_EXPR. (tsubst_copy_and_build): Likewise. * error.c (dump_expr): Handle PAREN_EXPR. * cxx-pretty-print.c (pp_cxx_expression): Likewise. * mangle.c (write_expression): Ignore PAREN_EXPR. * parser.c (cp_parser_decltype_expr): Split out... (cp_parser_decltype): ...from here. From-SVN: r197248 That commit also caused an ICE, and then this bug and the ICE were both fixed by: commit f9b381b8eb56252e302b88ea4fe89beffc33cf80 [r0-128726-gf9b381b8eb5625] Author: Jason Merrill Date: Wed Mar 5 19:25:37 2014 re PR c++/60409 ([c++1y] ICE on valid with template function) PR c++/60409 * semantics.c (force_paren_expr): Only add a PAREN_EXPR to a dependent expression. From-SVN: r208352
[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-04-02 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70822 Keywords||rejects-valid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Clang and EDG accept the code.
[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114536 --- Comment #5 from Jonathan Wakely --- (In reply to Fedor Chelnokov from comment #2) > May be just fail constant evaluation then instead of evaluating it to 0? Hmm, yes, it should fail to produce a constant expression.
[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114536 --- Comment #4 from Jonathan Wakely --- The padding bit has an indeterminate value. Because the result type is an unsigned char, the indeterminate bit does not produce undefined behaviour, but it's not allowed in a constant expression. I don't think this is a bug.
[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 --- Comment #3 from Jonathan Wakely --- [dcl.array] says that for T[N] the value "N specifies the array bound, i.e., the number of elements in the array; N shall be greater than zero." So T[0] is not a valid array type. And std::is_array has never been true for any traditional implementation based on partial specialization of class templates, only when switching to an intrinsic __is_array that fails to accurately give the same behaviour as the std::is_array trait. Since the purpose of the __is_array intrinsic is to optimize the std::is_array trait, it should have the same behaviour. For the optimization to change the behaviour of the trait seems like the tail wagging the dog.
[Bug libstdc++/100667] [11/12/13 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667 Jonathan Wakely changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |std::tuple cannot be |std::tuple cannot be |constructed from A&&, if A |constructed from A&&, if A |not defined (only forward |not defined (only forward |declared) |declared) --- Comment #13 from Jonathan Wakely --- Fixed on trunk now, thanks, Jason.
[Bug libstdc++/114519] GCC 14 trunk fails to compile chrono with -fno-char8_t -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-03-28 Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- The library doesn't require it, and can cope with -fno-char8_t
[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842 --- Comment #7 from Jonathan Wakely --- (In reply to GCC Commits from comment #3) > Adding that constrain completely breaks std::optional comparisons, > because it causes constraint recursion. To avoid that, an additional > check that U is not a specialization of std::optional is needed. That > appears to be a defect in the standard and should be reported to LWG. For the record, that is https://cplusplus.github.io/LWG/issue3566
[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #26 from Jonathan Wakely ---
What's bizarre about the PR 104606 case is that this fixes it:
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -1431,7 +1431,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#ifdef __cpp_lib_three_way_comparison
template
requires (!__is_optional_v<_Up>)
- && three_way_comparable_with<_Tp, _Up>
+ && three_way_comparable_with<_Up, _Tp>
constexpr compare_three_way_result_t<_Tp, _Up>
operator<=>(const optional<_Tp>& __x, const _Up& __v)
{ return bool(__x) ? *__x <=> __v : strong_ordering::less; }
[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #25 from Jonathan Wakely ---
It looks like PR 104606 is another case.
#include
#include
#include
struct Value : public std::variant> { };
struct Comparator {
template
bool operator<=(const T )
{
return true;
}
};
int main()
{
auto test2 = Comparator() <= std::optional{};
}
Preprocessing this with 10.4 and compiling with 11.1 fails, bisection shows it
started to fail with r11-2774.
[Bug libstdc++/104606] [11/12/13/14 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 --- Comment #13 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #5) > (In reply to Jakub Jelinek from comment #4) > > Just wild guess, perhaps the PR98842 changes between 11.1 and 11.2? > > That would mean it is a bug in GCC 10.4 also :(. It's not, even though 10.4 has the library change. Compiling the test case with 10.4 works. But preprocessing with 10.4 and then compiling with 11.1 fails, confirming a front end change is to blame. Bisection shows it started to error with r11-2774 c++: Check satisfaction before non-dep convs. [CWG2369] It's very hard to use concepts to protect a template from hard errors due to unwanted instantiation if constraints aren't checked until after doing all substitution and checking of non-dependent conversions. It was pretty straightforward to insert the satisfaction check into the logic, but I needed to make the 3-parameter version of satisfy_declaration_constraints call push_tinst_level like the 2-parameter version already does. For simplicity, I also made it add any needed outer template arguments from the TEMPLATE_DECL to the args. The testsuite changes are mostly because this change causes unsatisfaction to cause deduction to fail rather than reject the candidate later in overload resolution. gcc/cp/ChangeLog: DR 2369 * cp-tree.h (push_tinst_level, push_tinst_level_loc): Declare. * constraint.cc (satisfy_declaration_constraints): Use add_outermost_template_args and push_tinst_level. * pt.c (add_outermost_template_args): Handle getting a TEMPLATE_DECL as the first argument. (push_tinst_level, push_tinst_level_loc): No longer static. (fn_type_unification): Check satisfaction before non-dependent conversions.
[Bug libstdc++/104606] [11/12/13/14 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #12 from Jonathan Wakely --- std::optional's spaceship operator currently looks like this: template requires (!__is_optional_v<_Up>) && three_way_comparable_with<_Tp, _Up> constexpr compare_three_way_result_t<_Tp, _Up> operator<=>(const optional<_Tp>& __x, const _Up& __v) As Jakub noted, if we revert the LWG 3566 change it works: template _Up> constexpr compare_three_way_result_t<_Tp, _Up> operator<=>(const optional<_Tp>& __x, const _Up& __v) We can rewrite that to this, which should be exactly equivalent, and it still works: template requires three_way_comparable_with<_Up, _Tp> constexpr compare_three_way_result_t<_Tp, _Up> operator<=>(const optional<_Tp>& __x, const _Up& __v) and then we can add the !is-optional constraint back in: template requires (!__is_optional_v<_Up>) && three_way_comparable_with<_Up, _Tp> constexpr compare_three_way_result_t<_Tp, _Up> operator<=>(const optional<_Tp>& __x, const _Up& __v) And it still works! The only difference is: three_way_comparable_with<_Up, _Tp> vs three_way_comparable_with<_Tp, _Up> This should not matter, but it does. So there definitely seems to be a front end bug here, but at least there's an easy fix for the library.
[Bug libstdc++/104606] [11/12/13/14 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-27 Status|UNCONFIRMED |NEW --- Comment #11 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #2) > I am suspecting a front-end change caused this. > clang accepts the same code with libstdc++ which is another reason why I > think it might be a front-end issue. And clang accepts the example when using libc++, which also implements LWG 3566. So I don't think the LWG 3566 change itself is the problem.
