[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.2 --- Comment #9 from Jonathan Wakely --- Fixed for 14.2, thanks for the report (and to the dup reporters).
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added CC||pilarlatiesa at gmail dot com --- Comment #6 from Jonathan Wakely --- *** Bug 115134 has been marked as a duplicate of this bug. ***
[Bug libstdc++/115134] Possible typo in _Grapheme_cluster_iterator iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115134 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Already reported twice in the past 24 hours *** This bug has been marked as a duplicate of bug 115119 ***
[Bug libstdc++/115099] compilation error: format thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-17 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.2 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115121 --- Comment #4 from Jonathan Wakely --- I've opened PR 115121 for the accepts-invalid compiler bug.
[Bug c++/115121] New: ++this is accepted in uninstantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115121
Bug ID: 115121
Summary: ++this is accepted in uninstantiated template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct iter
{
void operator++(int) {
auto tmp = *this;
++this;
return tmp;
}
};
This has a typo, it should be ++*this
I assume this compiles because `this` is dependent, but we could reject it
earlier. Incrementing `this` is never valid, it doesn't matter how the template
is instantiated.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jonathan Wakely --- It fails to compile if that member function is instantiated (which libstdc++ itself never does). /home/jwakely/gcc/15/include/c++/15.0.0/bits/unicode.h:805:11: error: increment of read-only location '(std::__unicode::__v15_1_0::_Grapheme_cluster_view >::_Iterator*)this' 805 | ++this; | ^~ /home/jwakely/gcc/15/include/c++/15.0.0/bits/unicode.h:805:11: error: lvalue required as increment operand But ++this could be rejected without treating it as a dependent expression. Anyway, I'll fix the library typo.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-16 --- Comment #2 from Jonathan Wakely --- Which would be ++*this ++this shouldn't even compile.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-15 Resolution|INVALID |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #10 from Jonathan Wakely --- I'm reopening this to deal with it as a libstdc++ bug, because LWG seems to support changing the standard so that this Just Works. https://cplusplus.github.io/LWG/issue4101
[Bug c++/104426] -fsanitize=undefined causes constexpr failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-15 Ever confirmed|0 |1
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 Jonathan Wakely changed: What|Removed |Added Summary|libstdc++ build with|[14/15 Regression] |'-fno-rtti' is broken |libstdc++ build with ||'-fno-rtti' is broken Keywords||build Target Milestone|--- |14.2
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for 13.3 and 14.2, thanks for the report.
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 --- Comment #7 from Jonathan Wakely --- Fixed for 13.3 and 14.1 so far, I still plan to backport this to gcc-12 too.
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/114866] [14 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> + using _ValT = typename iterator_traits<_InputIterator>::value_type;
> + if constexpr (is_same_v<_ValT, _Tp>)
> + if constexpr (__is_byte<_ValT>::__value)
We can do better than this.
We can use memchr to find a char in a range of signed char, or even to find an
int in a range of signed char, as long as we're careful about values.
For example, given s = "abc"sv, std::find(s.begin(). s.end(), 'a'+0) should
find a match, but std::find(s.begin(), s.end(), 'a'+256) should not (even
though memchr would match in that case, because it does (unsigned
char)('a'+256)).
We should also ensure that std::ranges::find gets the same optimizations.
[Bug libstdc++/115040] Missed optimization opportunity in std::find of std::vector elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 --- Comment #5 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #4) > Then this is partly a dup of bug 88545 Yes, that would manually transform the find_epi8 case into a memchr call, but Clang doesn't need a manual transform in the library, it does it in the compiler. Tamar's plan to remove the manual loop unrolling in our std::find_if might help here, but I'm not sure.
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from Jonathan Wakely ---
(In reply to Georg Sauthoff from comment #0)
> Created attachment 45259 [details]
> specialize std::find to memchr for character searches in continous memory
>
> If std::find() is called with continuous random access iterators and a
> trivial char sized value, then calling memchr() is much more efficient than
> calling into the generic __find_if().
>
> The attached patch implements this optimization.
>
> That means it specializes a std::find helper on the iterator category and
> the value and calls __builtin_memchr() if possible.
Why specialize on the iterator category, when the __is_simple boolean already
checks if the iterator is a pointer?
The condition of a trivial byte-sized type seem insufficient, because you could
have:
struct B {
char c;
bool operator==(const B& b) const { return true; }
};
I would prefer to do simply:
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -3846,6 +3846,32 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
__glibcxx_function_requires(_EqualOpConcept<
typename iterator_traits<_InputIterator>::value_type, _Tp>)
__glibcxx_requires_valid_range(__first, __last);
+
+#if __cpp_if_constexpr
+ using _ValT = typename iterator_traits<_InputIterator>::value_type;
+ if constexpr (is_same_v<_ValT, _Tp>)
+ if constexpr (__is_byte<_ValT>::__value)
+#if __cpp_lib_concepts
+ if constexpr (contiguous_iterator<_InputIterator>)
+ {
+ if (const size_t __n = __last - __first)
+ {
+ auto __p0 = std::to_address(__first);
+ if (auto __p1 = __builtin_memchr(__p0, __val, __n))
+ return __first + (__p1 - __p0);
+ }
+ return __last;
+ }
+#else
+ if constexpr (is_pointer_v<_InputIterator>)
+ {
+ if (const size_t __n = __last - __first)
+ if (auto __p = __builtin_memchr(__first, __val, __n))
+ return __p;
+ return __last;
+ }
+#endif
+#endif
return std::__find_if(__first, __last,
__gnu_cxx::__ops::__iter_equals_val(__val));
}
I think we're going to remove the manual loop unrolling in __find_if for GCC
15, which should allow the compiler to optimize it better, potentially
auto-vectorizing. That might make memchr less advantageous, but I think it's
worth doing anyway.
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug 86172 depends on bug 115067, which changed state. Bug 115067 Summary: Bogus -O2 -Wnull-dereference for istreambuf_iterator https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug libstdc++/105580] [12/13/14/15 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580 Jonathan Wakely changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #8 from Jonathan Wakely --- *** Bug 115067 has been marked as a duplicate of this bug. ***
[Bug middle-end/115067] Bogus -O2 -Wnull-dereference for istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Dup *** This bug has been marked as a duplicate of bug 105580 ***
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #8 from Jonathan Wakely --- Hmm, you could be right. It looks like the printf in Apple libc doesn't print "-nan" even when not converting from float to double. According to https://developer.r-project.org/Blog/content/post/2020-11-02-apple-silicon.html the Apple silicon NaN payloads are not propagated by default, but I don't know if that means the signbit is not propagated. I assumed it meant they were running in default NaN mode.
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |13.3 Keywords||rejects-valid Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2024-05-13 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/115059] Constraints/Mandates on the comparison operators of std::optional and std::variant are overly strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115059 --- Comment #1 from Jonathan Wakely --- I don't want to change anything in libstdc++ here. Either std::is_convertible should be sufficient to check "convertible to" constraints, or "convertible to" should exclude these kind of games.
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #20 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #19)
> Similar argument can IMO be used for eliding unused memory allocations. It
> is kind of up to std::vector implementation on how many
> allocations/deallocations it does, right?
It's up to std::allocator, which is not required to call operator new every
time memory is needed.
> So we need a way to annotate the new/delete calls in the standard library as
> safe for such optimizations (i.e. implement clang's
> __bulitin_operator_new/delete?)
Yes, see PR 110137.
> How clang manages to optimize this out without additional hinting?
It supports __builtin_operator_{new,delete} and libstdc++ uses that when
compiled with clang.
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 --- Comment #6 from Jonathan Wakely --- Yes
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #6 from Jonathan Wakely --- (In reply to Joseph S. Myers from comment #2) > If a conversion from float to double (for passing in variable arguments) > occurs at runtime on RISC-V, that will produce a positive-signed NaN (that's > what the RISC-V floating-point instructions do). Cf. > https://sourceware.org/bugzilla/show_bug.cgi?id=29501 (for strfrom > functions). This seems to happen on Apple M1 chips too.
[Bug c++/95659] Inconsistent error message in "default argument missing for parameter"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95659 Jonathan Wakely changed: What|Removed |Added Severity|normal |minor
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 Jonathan Wakely changed: What|Removed |Added Severity|normal |minor
[Bug libstdc++/90857] stl::forward_list::erase_after crashes if __pos == __last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90857 Jonathan Wakely changed: What|Removed |Added Target Milestone|14.2|---
[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 #12 from Jonathan Wakely --- There's nothing fake about them, they are definitely inline functions as far as the language rules. But in some cases we don't want the compiler to use that fact as an optimisation hint.
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #6 from Jonathan Wakely --- What would be needed to work without it? It looks like the allocation would have to be larger so the size could be stored as a cookie at the start of the allocated block? Tangentially, could _M_alloc_size use __ba - 1 instead of __ba?
[Bug c++/71482] Add -Wglobal-constructors warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482 --- Comment #8 from Jonathan Wakely --- (In reply to Eric Gallager from comment #6) > Another reason this warning might be wanted: name mangling and demangling of > global constructors has been buggy for awhile now; see bug 54254 Looks like that's just a problem demangling the symbol name to print it in a human-readable form. What's buggy about the mangling?
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #3 from Jonathan Wakely --- P.S. what's optional is whether the compiler chooses to use that overload or not. But its presence is required for conformance.
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-03 CC||arsen at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- It's not optional, it's a required feature in C++14 and later. Failing to provide it is non-conforming, although GCC can be requested to be non-conforming the same way with -fno-sized-deallocation. Using that, the same error happens with GCC. We should either disable __cpp_lib_generator when __cpp_sized_deallocation is not defined, or change to not depend on it unconditionally.
[Bug libstdc++/77704] Data race on std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
--- Comment #10 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #5)
> For anyone interested, here is the workaround we came up with:
>
> // A data race happens in the libstdc++ (as of GCC 7.2) implementation of the
> // ctype::narrow() function (bug #77704). The issue is easily
> triggered
> // by the testscript runner that indirectly (via regex) uses ctype
> facet
> // of the global locale (and can potentially be triggered by other locale-
> // aware code). We work around this by pre-initializing the global locale
> // facet internal cache.
> //
> #ifdef _GLIBCXX_
> {
> const ctype& ct (use_facet> (locale ()));
>
> for (size_t i (0); i != 256; ++i)
> ct.narrow (static_cast (i), '\0');
> }
> #endif
It would be better to call ct.narrow(0, 0, 0, 0) as that will populate the
_M_narrow array and also set the _M_narrow_ok flag. Otherwise you can still get
later races on the flag.
[Bug c++/114934] Error message for expected unqualified-id could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114934 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/77704] Data race on std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #9 from Jonathan Wakely ---
There's a related data race in std::basic_ios::fill() because of these mutable
members:
mutable char_type _M_fill;
mutable bool _M_fill_init;
char_type
fill() const
{
if (!_M_fill_init)
{
_M_fill = this->widen(' ');
_M_fill_init = true;
}
return _M_fill;
}
That one's easier to fix.
[Bug libstdc++/114925] include/bits/fs_path.h#L841 deprecation note suggests UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Jonathan Wakely --- The suggestion is wrong anyway because _Source doesn't have to be a contiguous iterator, or any kind of iterator at all.
[Bug libstdc++/93672] [11/12 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 Known to work||13.2.1, 14.0 Summary|[11/12/13 Regression] |[11/12 Regression] |std::basic_istream::ignore |std::basic_istream::ignore |hangs if delim MSB is set |hangs if delim MSB is set --- Comment #8 from Jonathan Wakely --- Fixed for 13.3 and 14.1 so far.
[Bug libstdc++/104606] [11/12 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 Known to work||13.2.1, 14.0 Summary|[11/12/13 Regression] |[11/12 Regression] |comparison operator |comparison operator |resolution with |resolution with |std::optional and |std::optional and |-std=c++20 |-std=c++20 --- Comment #16 from Jonathan Wakely --- Fixed for 13.3 and 14.1 so far.
[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #18 from Jonathan Wakely ---
So maybe:
diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index aa7374bb252..662cff39df5 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -956,7 +956,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr bool
__maybe_has_padding()
{
-#if ! __has_builtin(__builtin_clear_padding)
+ // We cannot clear padding in the constructor for C++11,
+ // so return false here to disable all code for zeroing padding.
+#if __cplusplus < 201402L || ! __has_builtin(__builtin_clear_padding)
return false;
#elif __has_builtin(__has_unique_object_representations)
return !__has_unique_object_representations(_Tp)
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 36ff89a146c..336f27832fc 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,6 +238,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr atomic(_Tp __i) noexcept : _M_i(__i)
{
+ // A constexpr constructor must be empty in C++11,
+ // so we can only clear padding for C++14 and later.
#if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
__builtin_clear_padding(std::__addressof(_M_i));
[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>constexpr atomic(_Tp __i) noexcept : _M_i(__i)
>{
> -#if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
> +#if __has_builtin(__builtin_clear_padding)
> +#if __cplusplus >= 201402L
> if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
> +#endif
> __builtin_clear_padding(std::__addressof(_M_i));
> #endif
>}
Oh right, that still doesn't work in C++11:
/home/jwakely/gcc/15/include/c++/15.0.0/atomic: In constructor
'std::atomic<_Tp>::atomic(_Tp)':
/home/jwakely/gcc/15/include/c++/15.0.0/atomic:247:7: error: 'constexpr'
constructor does not have empty body
I remember hitting this when I implemented the padding stuff.
[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #16 from Jonathan Wakely --- Alternatively, we could skip all the padding cope in compare_exchange for C++11, since that was a C++20 change and not a DR.
[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #15 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr atomic(_Tp __i) noexcept : _M_i(__i)
{
-#if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
+#if __has_builtin(__builtin_clear_padding)
+#if __cplusplus >= 201402L
if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
+#endif
__builtin_clear_padding(std::__addressof(_M_i));
#endif
}
[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #14 from Jonathan Wakely --- Because a constexpr function can't have an if statement in C++11. But maybe we should just clear padding unconditionally for C++11.
[Bug libstdc++/114866] [14/15 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/650 ||419.html Keywords||patch Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650419.html
[Bug libstdc++/114147] [11 Regression] tuple allocator-extended constructor requires non-explicit default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jonathan Wakely --- Fixed for 11.5, 12.4, 13.3 and 14.1
[Bug c++/102257] call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-02 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > (In reply to Andrew Pinski from comment #2) > > See https://wg21.link/cwg1228 this might be invalid code and GCC is correct > > in rejecting it. > > So dup of PR 84849 ? This seems more closely related to Bug 113300, i.e. CWG 2856, because this is about explicit default ctors not explicit copy/move ctors.
[Bug c++/102257] call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257 Jonathan Wakely changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #7 from Jonathan Wakely --- *** Bug 114898 has been marked as a duplicate of this bug. ***
[Bug c++/114898] Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > Dup of Bug 102257, which might be what CWG 2586 says should happen, sadly. Oops 2856
[Bug c++/114898] Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- Dup of Bug 102257, which might be what CWG 2586 says should happen, sadly. *** This bug has been marked as a duplicate of bug 102257 ***
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.2
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 --- Comment #2 from Jonathan Wakely --- Only after the atomic wait/notify refactoring patches have landed.
[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 --- Comment #3 from Jonathan Wakely --- I've opened https://cplusplus.github.io/LWG/issue4084
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for 13.3 and 14.1, thanks for the report.
[Bug c++/114898] Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-30 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113300 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- Might be related to Bug 113300 and/or Bug 102257
[Bug c++/114898] Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #1 from Jonathan Wakely ---
Standalone testcase:
struct nullopt_t {
enum class Hidden { Token };
explicit constexpr nullopt_t(Hidden) noexcept { }
};
struct in_place_t {
explicit constexpr in_place_t() = default;
};
template
struct optional
{
template
optional(U&&) { }
optional(in_place_t);
optional(nullopt_t);
};
struct Widget {
int i[1];
};
optional r1( {{}} );
optional r2{ {} };
[Bug libstdc++/80977] uniform_int_distribution downscaling throws away perfectly good entropy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80977 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-30
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-30 --- Comment #2 from Jonathan Wakely --- It's only used for static assertions, so we can just disable those when the feature isn't supported. But it's not a big deal, Clang users can just not use for now.
[Bug libstdc++/114866] [14/15 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-04-28 Ever confirmed|0 |1 Summary| & out_ptr in |[14/15 Regression] |freestanding|& out_ptr in freestanding Status|UNCONFIRMED |NEW --- Comment #3 from Jonathan Wakely --- Yes, this is a regression, and should be fixed in the gcc-14 branch.
[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #2 from Jonathan Wakely ---
Libc++ has tests for "INF" (although only for long double, not float or
double), so it's apparently not accidental. The relevant code is:
if (floatfield == ios_base::fixed) {
if (uppercase)
*__fmtp = 'F';
else
*__fmtp = 'f';
That's been there since the initial commit in 2010.
MSVC behaves the same as libstdc++.
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #2 from Jonathan Wakely --- Maybe we could also make _M_localize more efficient for finite values by not even attempting to use grouping for scientific format.
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1734,7 +1734,7 @@ namespace __format
}
#endif
- if (_M_spec._M_localized)
+ if (_M_spec._M_localized && __builtin_isfinite(__v))
{
__wstr = _M_localize(__str, __expc, __fc.locale());
if (!__wstr.empty())
[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 --- Comment #1 from Jonathan Wakely --- Actually I think we're doing exactly what the standard requires: ios_base::fmtflags __fltfield = __flags & ios_base::floatfield; ... // [22.2.2.2.2] Table 58 if (__fltfield == ios_base::fixed) *__fptr++ = 'f'; when (flags & ios_base::floatfield) == ios_base::fixed the conversion specifier is %f and uppercase is not considered. There is no way to use a conversion specifier of %F with std::num_put. That seems odd, but it's what the standard says. Libc++ does what you expect, which seems to be non-conforming. I don't see any library issues about this, so I'll talk to the committee.
[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-26 Status|UNCONFIRMED |NEW
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2024-04-26 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |13.3
[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.
