https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79147
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> We might want to comment out STDC_HEADERS as well, instead of transforming
> it to _GLIBCXX_STDC_HEADERS
I'll keep this bug open until I've done that too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117005
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113504
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122032
--- Comment #1 from Jonathan Wakely ---
Please consider subscribing to the libstdc++ mailing list and making these
observations *before* the patches are committed to git.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122022
--- Comment #1 from Jonathan Wakely ---
There's no SIGSEGV, that's a compiler-explorer bug:
https://github.com/compiler-explorer/compiler-explorer/issues/5376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122022
--- Comment #5 from Jonathan Wakely ---
We can make it a rejects-valid testcase instead of a runtime abort:
#include
struct Obj {
Obj() = default;
Obj(const Obj&) = delete;
};
bool f(const Obj&) { return true; }
int main() {
Obj obj;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122022
--- Comment #4 from Jonathan Wakely ---
It looks like the parameters changed from forwarding references to values in
PATCHv5:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690816.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122022
Jonathan Wakely changed:
What|Removed |Added
CC||ncm at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121929
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122022
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> There's no SIGSEGV, that's a compiler-explorer bug:
> https://github.com/compiler-explorer/compiler-explorer/issues/5376
Actually this one:
https://github.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119740
--- Comment #3 from Jonathan Wakely ---
r16-3997-ga77146f01563b5df19e70061dc237178b5532aa9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79147
--- Comment #2 from Jonathan Wakely ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/695768.html
The diff that this produces in the gnerated c++config.h file is:
@@ -1531,25 +1533,25 @@
#define _GLIBCXX_LT_OBJDIR ".lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79147
--- Comment #3 from Jonathan Wakely ---
We might want to comment out STDC_HEADERS as well, instead of transforming it
to _GLIBCXX_STDC_HEADERS
gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118087
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117982
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121981
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 117982, which changed state.
Bug 117982 Summary: [C++23] Implement std::start_lifetime_as and
std::start_lifetime_as_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117982
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117402
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93906
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> I know r12-4069-ga09bb4a852f82a added the speed up way of doing
> conditional_t and internally using __conditional_t. Is the C++ front-end
> work still needed h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111963
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111568
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Created attachment 62405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62405&action=edit
prepr
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2545r4.pdf
It would be useful to have urcu in glibc
: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2530r3.pdf
Referenced Bugs:
https://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113460
--- Comment #6 from Jonathan Wakely ---
It was fixed on trunk by r15-3203-g5cca7517c5868b:
c++/coros: do not assume coros don't nest [PR113457]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113457
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956
--- Comment #7 from Jonathan Wakely ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/695568.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913
--- Comment #6 from Jonathan Wakely ---
Patch posted to replace 'auto'
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/695569.html
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121963
Jonathan Wakely changed:
What|Removed |Added
Blocks||103524
--- Comment #1 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956
--- Comment #6 from Jonathan Wakely ---
So maybe simply:
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -5460,9 +5460,7 @@ namespace views::__adaptor
public:
using iterator_category = input_iterator_tag;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121955
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
--- Comment #9 from Jonathan Wakely ---
Yes, for the other __relocate_a_1 overload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
--- Comment #7 from Jonathan Wakely ---
Oh but that's still wrong because we do want to do a single relocate loop for
the case where __alloc is not std::allocator. It's only for std::allocator that
_Destroy is a no-op.
So changing the definitio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
--- Comment #6 from Jonathan Wakely ---
That should be:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++17-extensions"
if constexpr (__is_trivially_destructible(_ValueType))
{
__result = std::__uninitial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820
--- Comment #4 from Jonathan Wakely ---
Yes, it should be ranges::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121942
--- Comment #10 from Jonathan Wakely ---
(In reply to Linas Vepstas from comment #7)
> What I'd really like to see in the standard is some function that compares
> two floats up to N ULPS. The underlying issue is that numeric algos tend to
> cho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
--- Comment #5 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #2)
> If I make __is_bitwise_relocatable false, we don't get memmove/memcpy
> for foo_int either.
If we didn't use __relocate at all, we'd also get memcpy. Because we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
--- Comment #4 from Jonathan Wakely ---
(In reply to Dmytro Ovdiienko from comment #0)
> It seems the issue is std::uninitialized_copy function. For some reason in
> order to use memcpy it requires the class to be trivially_constructible:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
--- Comment #3 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #2)
> __is_bitwise_relocatable currently defaults to __is_trivial, I think there
> is already an issue about replacing that with a weaker test,
We should be able to u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #6 from Jonathan Wakely ---
If you have working code for IEEE 128-bit long double (as used on arm64 and
optionally on power64) then I think the best thing to do for IBM128 long double
would be to_chars((__ieee128)value, ...) or equiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121942
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> ullabs is C26
Or C2y rather. I don't know when that is likely to be published.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121942
--- Comment #8 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> There is no ullabs in C++ yet (maybe C++26 will pull in ullabs from C23).
ullabs is C26 not C23, so won't be in C++26.
The proposal to add it to C was from 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121938
--- Comment #14 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #10)
> Looks like something changed between gcc 6 and 7 but I can't figure it out
> by just looking into changelog.
Bisections says r246965 changed it:
PR
: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: tkaminsk at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121890
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #19 from Jonathan Wakely ---
The problem is -fanalyzer-call-summaries
If I do
git checkout 6456da6bab8a2c43e7899afda991589065d96595^
libstdc++-v3/include/ext/atomicity.h
then the analyzer warnings come back. If I then make this c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121928
--- Comment #1 from Jonathan Wakely ---
Slightly simpler version of the "fix it by defining OLD_CODE" change, with a
little more context:
--- a/libstdc++-v3/include/ext/atomicity.h
+++ b/libstdc++-v3/include/ext/atomicity.h
@@ -92,24 +92,29 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121928
--- Comment #2 from Jonathan Wakely ---
The old code just does *mem += val with both values having type int, while the
new code does the arithmetic in unsigned and assigns back to the int. But apart
from one being well-defined for all values (no
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
r16-3810-g6456da6bab8a2c43e7899afda991589065d96595 for Bug 121148 caused a
number of new FAILs in the analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
Bug 71945 depends on bug 121148, which changed state.
Bug 121148 Summary: Should use modular arithmetic for _Atomic_word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
--- Comment #13 from Jonathan Wakely ---
Thanks for the reminder, fixed on trunk only so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #4 from Jonathan Wakely ---
You can bootstrap with --with-long-double-format=ieee to tell GCC to default to
IEEE long double on powerpc64le. That's what modern Linux POWER systems should
be using.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119739
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119739
--- Comment #2 from Jonathan Wakely ---
The most recent patch for this is
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693721.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
Jonathan Wakely changed:
What|Removed |Added
Summary|std::sort(par_unseq ,...) |[13/14/15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #1 from Jonathan Wakely ---
Using std::generate_canonical with anything except float, double and long
double is undefined:
https://eel.is/c++draft/rand#req.genl-1.4
There is a patch underway to rewrite generate_canonical, for P0952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #2 from Jonathan Wakely ---
(In reply to Cassio Neri from comment #0)
> 2) generate_canonical fails to compile on powerpc*
> (long double==IBM128):
You can stop testing this configuration, it isn't a good use of anybody's time
:-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121919
--- Comment #1 from Jonathan Wakely ---
N.B. the uniform random bit generator requirements extend the concept by
requiring result_type (and require that that type is not bool, which isn't
required by the concept).
std::uniform_int_distribution
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |16.0
Ever confirmed|0 |1
Last reconfirmed||2025-09-11
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The std::uniform_random_bit_generator concept does not require a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121890
--- Comment #2 from Jonathan Wakely ---
updated patch:
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/695191.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121917
Jonathan Wakely changed:
What|Removed |Added
Summary|ranges::shuffle incorrectly |[16 Regression]
|re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121918
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-09-11
Severity|normal
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
struct non_default_sentinel_t { };
template
bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
Bug 71945 depends on bug 121148, which changed state.
Bug 121148 Summary: Should use modular arithmetic for _Atomic_word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121782
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|NEW
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct A { };
struct B {
B() = default;
B& operator=(const B&) = delete;
B& operator=(const A&) cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121912
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Even if haystack is not random access but is bidirectional, we can _still_
> optimize the algo. Every time we match an element from the needle we can
> decre
: missed-optimization
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Given std::search(haystack, haystack_end, needle, needle_end) we always do a
linear
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
For the __rotate overload taking random access iterators, check that this
optimizes to memmove for contiguous iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121890
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Jonathan Wa
words: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
namespace __gnu_test
{
// Ensure that the itera
||2025-09-10
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80676
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121871
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121873
--- Comment #1 from Jonathan Wakely ---
How are you invoking the compiler? The assert doesn't fail for me on x86_64
Fedora 42.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120698
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.5
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121855
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121819
--- Comment #3 from Jonathan Wakely ---
(In reply to Romain Geissler from comment #0)
> Would it make sense to remove the "&& defined __STRICT_ANSI__" part on
> libstdc++ side so that type_traits work for the __int128 extension even in
> strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121811
--- Comment #16 from Jonathan Wakely ---
That would allow this in C++: ckd_add(&i, 'a', true)
But C++26 says that's ill-formed:
Mandates: Each of the types type1, type2, and type3 is a cv-unqualified
signed
or unsigned integer type.
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121811
--- Comment #14 from Jonathan Wakely ---
Andrew, what's the objection to GCC just putting #ifndef __cplusplus in our
header?
Do we have to make things harder for people?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121819
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> That works be an ABI break, and require a new glibc.
* That would be...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121814
--- Comment #1 from Jonathan Wakely ---
=
==204691==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7b3d11a00058 at pc 0x7f3d14a4b2cf bp 0x7ffe75781ae0 sp 0x7ffe757812b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121814
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> And __s += *c not __s += c;
>
> Don't you want to append single characters, not a char* that isn't even
> null-terminated?
of course the whole loop could b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121814
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Also, stop using names like _UIntPtrType and __s, those are reserved names.
See https://stackoverflow.com/q/228783/981959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121814
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121814
--- Comment #2 from Jonathan Wakely ---
for (auto c = __cs; c < __cs + __ilen; ++c)
__s += c;
Shouldn't that be __len not __ilen?
1 - 100 of 7849 matches
Mail list logo
