https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122088
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122105
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
--- Comment #10 from Jonathan Wakely ---
... and that has now been merged into the ABI document.
words: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
int main()
{
static_assert([] { return true; }); // oops
}
We get a correct warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122098
Jonathan Wakely changed:
What|Removed |Added
Blocks||59002
--- Comment #1 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151
--- Comment #12 from Jonathan Wakely ---
If we had a clear description of the warning (when it should/shouldn't warn,
whether it should be on or off by default, whether it should be part of an
existing warning, or the -Wstring-conversion one prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2024-03-14 00:00:00 |2025-9-30
--- Comment #9 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151
--- Comment #10 from Jonathan Wakely ---
A godbolt link is not a clear explanation of what behaviour you want from a new
warning. That shows precisely one case. Is that the only case that should warn?
Again:
If you want a new warning for those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224
--- Comment #9 from Jonathan Wakely ---
This avoids the warning, but we should probably just suppress it in the
testcase instead:
--- a/libstdc++-v3/include/std/generator
+++ b/libstdc++-v3/include/std/generator
@@ -616,6 +616,7 @@
re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103993
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-09-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103993
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> This seems like another case that triggers in the libstdc++ testsuite, for
> 23_containers/map/modifiers/insert/92300.cc
>
>
> Similar to comment 4, this i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122099
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> I think we've spoken about unsafe functions like strlen before, but I
> appreciate your reply. There's a missing n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121919
Jonathan Wakely changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #4)
> Could this bug cover warning when size_t is converted to bool? and int as
> well.
It's extremely common to do:
if (strlen(str))
...
or:
void copy(const X* fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
--- Comment #8 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> Note GCC 11.4.0 didn't ICE but accepted the code. clang/MSVC/EDG all reject
> the constexpr in a class with a virtual base class.
>
> Without a template GCC d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117158
Jonathan Wakely changed:
What|Removed |Added
CC||qingren2hxb at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122092
--- Comment #1 from Jonathan Wakely ---
This is already fixed. Please stop it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122091
--- Comment #2 from Jonathan Wakely ---
Again, this is already fixed. GCC 13.2.0 is old and outdated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122088
--- Comment #4 from Jonathan Wakely ---
GCC 15 just says:
122088.cc:13:9: error: expected ‘)’ before ‘...’ token
13 | Bar(Args...) -> Bar>;
|~^~~
| )
122088.cc: In function ‘int main()’:
122088.cc:16:11: error: cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
Jonathan Wakely changed:
What|Removed |Added
CC||qingren2hxb at gmail dot com
--- Comm
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
namespace X {
template struct S { };
template X::S(T) -> X::S;
}
I don't know if this is rejects-valid or just a diagno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122090
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122093
Jonathan Wakely changed:
What|Removed |Added
Keywords|rejects-valid |
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122093
--- Comment #2 from Jonathan Wakely ---
Hmm, on the other hand, [temp.deduct.guide] p3 says:
"The template-name shall be the same identifier as the template-name of the
simple-template-id."
So that would mean it has to be S and not X::S, in bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122093
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Jon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122092
--- Comment #3 from Jonathan Wakely ---
This one is even fixed for 13.4.0 so if you were just using a supported release
instead of the unsupported and outdated 13.2.0, you wouldn't see this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122092
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122090
Jonathan Wakely changed:
What|Removed |Added
Known to work||14.3.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122091
Jonathan Wakely changed:
What|Removed |Added
Known to work|14.3.0 |15.1.0
Known to fail|14.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121963
--- Comment #7 from Jonathan Wakely ---
Can you please fix your new blog post to not misattribute Nathaniel's comment
to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122083
--- Comment #3 from Jonathan Wakely ---
The reduced testcase only gives one warning, but running the version in the
testsuite with -Wnonnull gives two warnings:
FAIL: 25_algorithms/lexicographical_compare_three_way/1.cc -std=gnu++20 (test
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122083
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Seems to be a regression caused by
> r15-3328-g673a448aa24efedd5ac140ebf7bfe652d7a6a846
>
> "Optimize initialization of small padded objects"
That's what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122083
Jonathan Wakely changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
FIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 95507
Target Milestone: ---
Reduced from 25_algo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119721
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
static decimal32 make_decimal32(long long __coeff, int __exp);
static decimal32 make_decimal32(unsigned long long __coeff, int __exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122062
--- Comment #5 from Jonathan Wakely ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122062
--- Comment #3 from Jonathan Wakely ---
Specifically, vector::iterator. If it was vector::iterator
it would need the fix. It doesn't hurt to make __normalize immune from evil
commas. It's a good habit to do it anywhere a for loop increments more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122062
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=122062
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79147
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122061
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> That means you cannot warn when compiling the original example, because the
> destructor is not necessarily wrong.
>
> But if you compile code that actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122061
--- Comment #5 from Jonathan Wakely ---
That means you cannot warn when compiling the original example, because the
destructor is not necessarily wrong.
But if you compile code that actually uses the constructor and destructor, then
GCC already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122061
--- Comment #4 from Jonathan Wakely ---
void f()
{
S s;
std::swap(s.p1, s.p2);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122061
--- Comment #3 from Jonathan Wakely ---
This would have to be a flow-sensitive warning, something like -fanalyzer. Code
could change the pointers between the constructor and destructor, so you can't
assume that the destructor is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70358
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97728
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65114
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #9 from Jonathan Wakely ---
I submitted an NB comment for C++26 about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89118
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109772
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82749
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
--- Comment #2 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112925
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119794
--- Comment #3 from Jonathan Wakely ---
Implemented for GCC 16, but currently only for 64-bit targets with __int128
support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118087
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
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
1 - 100 of 7909 matches
Mail list logo
