[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- Fixed for 13.4 and 14.2
[Bug c++/110137] implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137 --- Comment #7 from Jonathan Wakely --- Thanks for the patch, but patch review happens on the mailing list, not in bugzilla. Please repost to gcc-patches as documented in the submission guidelines, thanks.
[Bug libstdc++/115209] The implementation of concat_view refers to p2542r7 rather than the p2542r8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209 --- Comment #1 from Jonathan Wakely --- As already noted at https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652571.html
[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 --- Comment #11 from Jonathan Wakely --- The fix is in 13.1
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 --- Comment #13 from Jonathan Wakely --- (In reply to Alan Coopersmith from comment #11) > While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins > from pkgsrc found that just removing the definition of __STDC_VERSION__ > didn't work with some of the illumos headers: > https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md So the illumos sys/feature_tests.h is using __STD_VERSION__ to mean "the version of the C library to expose for the current language mode", whether that language mode is a C language mode or a C++ one. And that's an entirely reasonable use of it IMHO, and conforms to the C++ standard. I stick by what I said in comment 4: code which assumes that __STDC_VERSION__ being defined implies a C compiler is being used is **broken C++ code**. There is no compliance requirement why GCC should stop defining __STDC_VERSION__, and there's a good reason to keep defining it if defining it is needed (or just helpful) for a target's libc headers. The Cython code quoted in the illumos notes should be fixed to check the __cplusplus condition first, then if __cplusplus is not defined check __STDC_VERSION__. It's just bad code. N.B. since C++23 #include works in C++ anyway: https://wg21.link/P0943R6
[Bug c++/115196] Bad error message when using library functions from versions before they were introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196 --- Comment #4 from Jonathan Wakely --- (In reply to Halalaluyafail3 from comment #0) > This note doesn't seem to be very helpful, it mentions adding an extra > '#include' when one is already present. A better error message here > would be to omit the note, or to make it mention changing the selected C++ > standard version. If you'd tried gcc trunk on godbolt you'd have seen that's exactly what happens: :3:10: note: 'std::to_address' is only available from C++20 onwards There was just a typo which made gcc think std::to_address is part of in C++11, so if it wasn't declared in your program then it must be because you didn't include . After the fix it correctly suggests using at least C++20.
[Bug c++/115196] Bad error message when using library functions from versions before they were introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196 --- Comment #3 from Jonathan Wakely --- You seem to imply it's a general problem, but I think it's specific to sd::to_address, and that's already fixed.
[Bug c++/107500] [12 Regression] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #29 from Jonathan Wakely --- Fixed for 12.4 and up.
[Bug libstdc++/115099] compilation error: format thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 14.2, thanks for the report.
[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 Target Milestone|--- |13.4 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #8 from Jonathan Wakely --- We have the same problem in
[Bug libstdc++/79384] Clang doesn't like variant's std::visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79384 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Jonathan Wakely --- I can't reproduce this now. It might have been the same as Bug 90397 which was fixed for 9.2, or it might have been related to https://bugs.llvm.org/show_bug.cgi?id=31852 The test case compiles fine with clang 17 and libstdc++ headers from GCC 7.5, 8.x, 9.2, or later.
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jonathan Wakely --- Fixed for 13.4 and 14.2
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Jonathan Wakely --- Fixed for 13.4 and 14.1
[Bug c++/102774] Stop showing "error: variable or field ‘f’ declared void" after an earlier error in a declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102774
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-05-18 00:00:00 |2024-5-21
--- Comment #5 from Jonathan Wakely ---
Another one:
template void func(T) { }
f.cc:1:48: error: variable or field ‘func’ declared void
1 | template void func(T) { }
|^~~~
f.cc:1:53: error: ‘T’ was not declared in this scope
1 | template void func(T) { }
| ^
[Bug c++/115173] GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
--- Comment #2 from Jonathan Wakely ---
Further reduced:
struct string { string(int) { } };
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
Still garbage though.
[Bug c++/115173] GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-21
Keywords||diagnostic,
||ice-on-invalid-code,
||memory-hog
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
I'm marking this as ice-on-invalid-code, even though it gets killed rather than
ICE-ing. But it is invalid.
The summary seems misleading, there are no nested initializer lists here. It's
just syntactically ill-formed code with mismatched braces and parentheses.
And most of the functions are irrelevant to the exponential code.
Reduced:
#include
struct string { string(std::initializer_list) { } };
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
}
This seems like auto-generated garbage, not something anybody would ever write
by accident, so should be very low priority.
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 --- Comment #8 from Jonathan Wakely --- (In reply to Amatul Adeeba from comment #6) > I mean even after trying the typo that is mentioned above, the error still > occurs. No it doesn't, it gives the correct error: 107800.cc: In function 'int main()': 107800.cc:5:8: error: 'to_address' is not a member of 'std' 5 | std::to_address(p); |^~ 107800.cc:5:8: note: 'std::to_address' is only available from C++20 onwards N.B. after fixing the typo you need to remove gcc/cp/std-name-hint.* in the GCC source dir, so that those files are recreated from the csv file. If you don't do that, you won't get the fix.
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|13.4|14.0 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > Fixed on trunk so far. I'm not sure why I set the target milestone to 13.3, as chrono::parse isn't present in the gcc-13 branch at all. So this bug only affected gcc-14 and was fixed in time for the 14.1 release.
[Bug c++/115160] Enabling undefined behaviour sanitizer causes or'ed bit shift to report wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115160 --- Comment #5 from Jonathan Wakely --- Specifically, std::vector::iterator::operator++(int) is "just a function", so the compiler doesn't "know" that it modifies the iterator every time it's called. To the compiler, the code looks like: (deref(inc(b)) | (deref(inc(b)) << 8) | (deref(inc(b)) << 16) | (deref(inc(b)) << 24) And this isn't clear that this modifies b and that the result depends on the unspecified order that each deref(inc(b)) subexpression is evaluated. But that doesn't really matter anyway. I don't think there is actually any undefined behaviour here at all, so UBsan should not give any errors. Evaluation of each *b++ subexpression happens before the evaluation of the next one. But the standard doesn't specify which one is "the next one". It's not undefined, but it's unspecified. So it's valid for the compiler to evaluate it left-to-right, but also valid to evaluate it right-to-left, or any other order as long as the b++ evaluations do not interleave.
[Bug c++/115163] Requesting better diagnostic for explicit constructor failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115163 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/111230] show explicit functions in possible candidates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111230 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=36183 --- Comment #2 from Jonathan Wakely --- Dup of PR 36183? There Jason said: We'd probably get that by changing add_candidates to mark an explicit candidate as bad rather than non-viable, and then adding the explanation to convert_like_real.
[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?
