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
||jason at gcc dot gnu.org
Status|RESOLVED|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
at gcc dot gnu.org |jason at gcc dot gnu.org
CC||jason at gcc dot gnu.org
--- Comment #17 from Jason Merrill ---
Fixed on trunk by r16-325-g25fe59805029e1 for PR119162.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012
--- Comment #4 from Jason Merrill ---
(In reply to Jason Merrill from comment #3)
> On branches I'm thinking to give the warning under -Wabi=0. It's awkward
> that plain -Wabi currently gives a warning, though that could change.
That is, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012
--- Comment #3 from Jason Merrill ---
(In reply to Richard Biener from comment #2)
> going to be interesting to decide what to do on branches ... does it affect
> the ABI of any part of libstdc++, in the shared object or instantiated
> templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119859
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2025-04-30
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119305
--- Comment #4 from Jason Merrill ---
(In reply to Patrick Palka from comment #3)
> Jakub/Jason, shall we backport r15-521 to the 14 branch in order to fix this
> PR for 14.3?
That would make sense to me, but let's see what Jakub thinks.
||2025-04-29
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned 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=119916
--- Comment #18 from Jason Merrill ---
(In reply to Iain Sandoe from comment #17)
> > > In the meantime, perhaps it would be enough to revert the "fix" for
> > > PR115908
> > > (and presumably mark that as INVALID?) - or do you have other thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #16 from Jason Merrill ---
(In reply to Iain Sandoe from comment #15)
> hmm .. EWG does seem to iterate at times ... maybe I can reach out to Lewis
> for the example (and to ask him how Ville's request is intended to be
> handled).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|1
CC||jason at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Jason Merrill ---
This changed in r15-3721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117530
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
Bug 107430 depends on bug 117530, which changed state.
Bug 117530 Summary: [14 Regression] Mismatch of lambda type with itself in
recursive alias declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117530
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360
Jason Merrill changed:
What|Removed |Added
Target Milestone|13.4|15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119859
--- Comment #9 from Jason Merrill ---
One of the EDG developers points out that the difference is not with CWG2273
but rather that in other compilers the base template is not brought in by the
derived template. Before P1787 only the parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119859
--- Comment #7 from Jason Merrill ---
(In reply to Richard Biener from comment #6)
> This seems to be kind-of SUSPENDED if the standard is ambiguous. It might
> be reasonable to go back to the previous behavior for the ambiguous case.
I didn'
1 - 100 of 3334 matches
Mail list logo
