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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121811
--- Comment #10 from Jonathan Wakely ---
On the other hand, if I'm going to go to all the trouble of adding a new header
then I might as well just backport r15-8036-gd4c7de7dc925e7 and add the working
header to gcc-14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121811
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=121804
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536
--- Comment #11 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #10)
> Does it make sense to revert the libstdc++
> change once the fix goes in?
I don't think so. Keeping the init seems preferable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121097
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.5
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121745
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110853
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #21 from Jonathan Wakely ---
Very few things are explicitly instantiated.
It's really only std::string, and iostreams. Do we need to aggressively inline
iostreams? They make use of virtual functions and opaque APIs (like
std::locale)
||2025-09-04
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
(In reply to Avi Kivity from comment #0)
> Likely the memcpyable detection web gets confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121790
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gc
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 106749
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3235r3.html
This was approved as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121789
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Avi Kivity from comment #0)
> > Likely the memcpyable detection web gets confused by the move_iterator
>
> Yes, I think that is the reason.
II
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121789
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> If the user somehow gets their arguments wrong, we can either use memcpy to
> read+write outside of bounds, or trap on __last < __first, or do nothing.
To b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121789
--- Comment #4 from Jonathan Wakely ---
(In reply to Avi Kivity from comment #2)
> (testq/jle sequence)
>
> The jle itself is from libstdc++:
Ah right.
> I believe it's undefined to have __last not be reachable by incrementing
> __first, so !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121782
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110853
Jonathan Wakely changed:
What|Removed |Added
Summary|[13/14/15/16 Regression]|[13/14/15 Regression] Bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121771
Jonathan Wakely changed:
What|Removed |Added
Known to fail||12.2.0, 13.1.0, 14.3.0,
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: ---
Split out from Bug 110853:
#include
void func() {}
std::tuple t(func);
std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121765
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110853
--- Comment #8 from Jonathan Wakely ---
(In reply to Patrick Palka from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > This is a regression caused by the new concepts-based constructor
> > constraints in gcc 12.
> And the analog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121496
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121374
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
IRMED
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
void func() {}
std::pair p(func, 1);
std::pair& r =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110853
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment
|1
Last reconfirmed||2025-09-02
Known to fail||11.5.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Summary|[c++-concepts] Bad |[13/14/15/16 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121761
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110853
--- Comment #3 from Jonathan Wakely ---
This should fix it:
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -445,7 +445,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/// Constructor accepting lvalues of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121761
Jonathan Wakely changed:
What|Removed |Added
Known to work||11.5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121745
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121760
--- Comment #18 from Jonathan Wakely ---
Please attach preprocessed source as requested at https://gcc.gnu.org/bugs
That's more useful than a dozen separate files that need to be included
correctly, which is why we ask for it in the bug reporti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117639
--- Comment #8 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #1)
> Does std::log need to set errno?
Yes, it's the same log function as in C.
So log((unsigned)0) sets ERANGE and log ((signed)-1) sets EDOM. But I would
expect th
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121745
--- Comment #2 from Jonathan Wakely ---
Oops the ones that take const pair&& need to use forward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121745
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121690
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 114298, which changed state.
Bug 114298 Summary: std::lazy_split_view constructor is currently not explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119744
Jonathan Wakely changed:
What|Removed |Added
CC||michael.kenzel at gmail dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121748
--- Comment #1 from Jonathan Wakely ---
Giuseppe has a WIP patch for this, which Tomasz might complete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
--- Comment #10 from Jonathan Wakely ---
Should we close this as fixed, or keep it open until the testsuite can import
std?
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/2025/p2988r12.pdf
Referenced Bugs:
https://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121741
--- Comment #2 from Jonathan Wakely ---
We can certainly use always_inline in some functions, but I don't think we want
it for everything that contains a hardened assertion.
So maybe we could use either always_inline or abi_tag on all hardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #13 from Jonathan Wakely ---
N.B. std::breakpoint() doesn't necessarily need to be recoverable.
(I've pushed an implementation of the C++ header to gcc trunk.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121720
--- Comment #1 from Jonathan Wakely ---
Possibly caused by r15-3986-g3e1bd6470e4deb but I'm not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119670
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
Bug 110339 depends on bug 119670, which changed state.
Bug 119670 Summary: [C++26] Implement P2546R5, Debugging Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119670
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121705
--- Comment #4 from Jonathan Wakely ---
This does fix it, but probably shouldn't be needed:
-- a/libstdc++-v3/src/c++23/std.cc.in
+++ b/libstdc++-v3/src/c++23/std.cc.in
@@ -3415,3 +3415,7 @@ export namespace std
}
using std::hash;
}
+
+e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121705
--- Comment #3 from Jonathan Wakely ---
Hmm, on the other hand, we probably shouldn't need to export that explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121705
--- Comment #2 from Jonathan Wakely ---
Probably r16-1709-g4b3cefed1a0834
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121705
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121685
--- Comment #9 from Jonathan Wakely ---
(In reply to Richard Biener from comment #6)
> So the actual testcase (from CPU 2017 leela) is more like the following where
> IMO hoisting of the data start pointer should be OK since 'this' should be
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121685
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121685
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> So even though m_mcowner cannot possibly be bound to nullptr it might still
> bind to a released object? Likewise may it bind to an object of
> insufficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110352
--- Comment #3 from Jonathan Wakely ---
Also:
Padded mdspan layouts https://wg21.link/p2642r6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119128
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-08-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121690
--- Comment #9 from Jonathan Wakely ---
(In reply to Sam James from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I remember hearing about some issue in this area before too.
>
> Two things come to mind:
> 1) An issue NightStrik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120611
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121677
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121671
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107792
--- Comment #6 from Jonathan Wakely ---
Please open a new bug report for the regression, as this isn't likely to get
any attention here. CC me and Arsen and maybe iains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121374
--- Comment #7 from Jonathan Wakely ---
Yes, maybe I looked it up and forgot to include the implicit leading 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #19 from Jonathan Wakely ---
I'm seeing a new libstdc++ testsuite failure since r16-3022-gbc42128330c0ea
FAIL: 20_util/variant/102912.cc -std=gnu++20 (test for excess errors)
FAIL: 20_util/variant/102912.cc -std=gnu++23 (test for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91319
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
1 - 100 of 7797 matches
Mail list logo
