https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120800
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #20 from Jason Mer
at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121244
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
Jason Merrill changed:
What|Removed |Added
Target Milestone|16.0|15.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120620
--- Comment #6 from Jason Merrill ---
(In reply to Patrick Palka from comment #5)
> Do we intend to attempt constant evaluation of user-written __dynamic_cast
> calls? If so, we need to make cxx_eval_dynamic_cast_fn robust to
> non-constant/non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121244
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
at gcc dot gnu.org |jason at gcc dot gnu.org
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Comment #10 from Jason Merrill ---
Fixed for 14.4/15.2/16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #17 from Jason Merrill ---
OK, the issue is that we currently don't represent trivial initialization at
all, so the initial placement new has no effect.
Then the trivial destructors are represented by clobbers, but constant
evaluati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #15 from Jason Merrill ---
(In reply to Tomasz Kamiński from comment #14)
Please provide complete testcases, this snippet isn't enough to reproduce.
at gcc dot gnu.org |jason at gcc dot gnu.org
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
Jason Merrill changed:
What|Removed |Added
Attachment #61891|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #11 from Jason Merrill ---
(In reply to Tomasz Kamiński from comment #9)
> I remember that LWG3436 was discussed in core in Varna
> (https://wiki.edg.com/bin/view/Wg21varna/CoreWorkingGroup#LWG3436) and the
> current wording is resul
|NEW
Last reconfirmed||2025-07-21
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Comment #8 from Jason Merrill ---
(In reply to Tomasz Kamiński from comment #6)
> I believed that `_member` being active after new sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #5 from Jason Merrill ---
The intent of the patch was to support
new (&union_.member) T
syntax like
union_.member = T()
for setting the active member, as in
https://eel.is/c++draft/class.union#general-example-3
but adding the li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 87097, which changed state.
Bug 87097 Summary: value-initialization of an array of more than 1 element not
treated as a constant initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87097
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87097
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #3 from Jason Merrill ---
Created attachment 61891
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61891&action=edit
fix
Let me know how this works for you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #17 from Jason Merrill ---
As I commented at
https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b-e6c16a34c...@redhat.com/
we could optimize the dynamic_cast to type_info::operator== instead of vtable
comparison.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121053
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #40 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #34)
> Anyway, will defer this to Jason, the change to only do what() printing if
> derived from std::exception was fairly small and can be always reverted if
> there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #12 from Jason Merrill ---
(In reply to Iain Sandoe from comment #10)
> that's fine too - my plan is to back port the stack of changes made on trunk
> rather than doing piecemeal - to try and avoid churn..
Yeah, backporting this pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
Jason Merrill changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #25 from Jason Merrill ---
(In reply to Frank Heckenbach from comment #24)
> auto f (S );
Right, this is one of the cases fixed for GCC 16 by my commit above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #23 from Jason Merrill ---
(In reply to Frank Heckenbach from comment #21)
> So my question stands.
Then yes, it does look like it should work; libstdc++ uses that 'requires
function call' pattern in
template
concept __is_der
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
Jason Merrill changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120953
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120575
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||jason at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120684
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120716
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120748
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120748
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120716
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
|1
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Last reconfirmed||2025-07-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #15 from Jason Merrill ---
We always intended to diagnose Concepts TS features that didn't make it into
C++20, but there was a bug in GCC 12 that we didn't diagnose that particular
case because it hit the transformation from
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120678
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|1
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Last reconfirmed||2025-06-17
||jason at gcc dot gnu.org
Last reconfirmed||2025-06-11
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119064
--- Comment #3 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #2)
> The patch is on top of the
> https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686210.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686211.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120502
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120555
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 120123, which changed state.
Bug 120123 Summary: [13 Regression] Implicit this is not used in a requires
clause in nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120502
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120506
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
Jason Merrill changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[13 Regression] Implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
||2025-06-02
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #9 from Jason Merrill ---
Created attachment 61560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61560&action=edit
regression fixes
Thanks, now testing these fixes for those three issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
--- Comment #15 from Jason Merrill ---
(In reply to Nathaniel Shead from comment #14)
> Created attachment 61550 [details]
> pr113563 testcase
>
> I'd briefly started looking at this a while back and had written some tests,
> but I'd gotten stu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
--- Comment #13 from Jason Merrill ---
Fixed for 16 so far.
at gcc dot gnu.org |jason at gcc dot gnu.org
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #15 from Jason Merrill ---
(In reply to Iain Sandoe from comment #14)
> * If we add the non-coroutine simulation of the ramp, then clang-20 also
> complains - but with a different diagnostic:
>
> ":97:10: error: call to implicitly-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #13 from Jason Merrill ---
In the original testcase we do choose to do NRVO, but this fails
/* Don't check copy-initialization for NRV in a coroutine ramp; we
implement this case as NRV, but it's specified as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #12 from Jason Merrill ---
(In reply to Iain Sandoe from comment #11)
Good point, in the reduced testcase, under
https://eel.is/c++draft/class.mem#class.copy.ctor-8 TaskBase doesn't get a move
constructor at all. But in the origina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #10 from Jason Merrill ---
(In reply to Iain Sandoe from comment #9)
> OK so the reason this fails is because check_return_expr() concludes that we
> cannot do NRVO
Yes, because the implementation is permitted to use temporary objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #14 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Hana Dusíková from comment #12)
> > I'm using [[gnu::used]] to emit constexpr symbol so it can be part of
> > compatible interface.
Sure, that wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #11 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #7)
> where making the destructor constexpr and thus effectively inline would have
> terrible effects, virtual tables of exception and similar classes now
> emitted e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #9 from Jason Merrill ---
I had been thinking thinking that exception_ptr would become compiler magic,
since it's unspecified by the standard, while std::exception would not, since
it's a standard class that is regularly derived from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #6 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #3)
> Jonathan, thoughts on the library side?
> E.g. std::uncaught_exceptions is just declared in the header, but if it
> needs to be constexpr it needs some inline de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116954
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Jason Merrill changed:
What|Removed |Added
Attachment #61500|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95298
--- Comment #12 from Jason Merrill ---
I'm reluctant to backport mangling fixes, and the PR says this was broken as
far back as GCC 7, so I lean toward not backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117817
--- Comment #5 from Jason Merrill ---
That patch also introduced PR120385, so we shouldn't just backport it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264
--- Comment #11 from Jason Merrill ---
This caused PR120385.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #13 from Jason Merrill ---
Created attachment 61500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61500&action=edit
possible fix
Does this fix the issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
|UNCONFIRMED |NEW
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jason Merrill ---
https://cplusplus.github.io/CWG/issues/2548.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120204
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
|ASSIGNED
CC||jason at gcc dot gnu.org
Last reconfirmed||2025-05-09
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120185
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #19 from Jason Merrill ---
(In reply to Jason Merrill from comment #14)
> It's frustrating that apparently EWG got to see an example but it isn't
> preserved anywhere.
Ah, seems like this is it:
https://github.com/GorNishanov/await/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 107744, which changed state.
Bug 107744 Summary: Error in constant evaluation of dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107744
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107744
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944
--- Comment #19 from Jason Merrill ---
*** Bug 107744 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944
--- Comment #18 from Jason Merrill ---
*** Bug 99018 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99018
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 115207, which changed state.
Bug 115207 Summary: [constexpr] constexpr assignment rejected as non const on
self-assignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207
What|Removed
1 - 100 of 3353 matches
Mail list logo
