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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120506
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2025-05-22
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120204
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120204
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120185
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120185
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2025-05-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
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
St
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
Sta
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2025-05-02
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119964
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2025-04-28
Ever confirmed|0
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'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119859
--- Comment #4 from Jason Merrill ---
(In reply to Andrew Pinski from comment #2)
> GCC trunk seemly only rejects the template member function as being
> ambigious though.
Yes, because https://eel.is/c++draft/namespace.udecl#11 says "The set of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119859
--- Comment #5 from Jason Merrill ---
(In reply to Andrew Pinski from comment #3)
> Another example:
...
> template
> const A& h();
...
> b.h();
T cannot be deduced in this call, so A::h is not a viable candidate, so it's
not ambiguous.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772
Jason Merrill changed:
What|Removed |Added
Target Milestone|13.4|12.5
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116954
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
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=113835
Jason Merrill changed:
What|Removed |Added
CC||daklishch at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #18 from Jason Merrill ---
If I increase the limits (or reduce N) enough that we get through the whole
evaluation, constant-evaluation still fails right at the end because the result
refers to the result of operator new and we don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #17 from Jason Merrill ---
Clang shows the same behavior, taking a long time to give up and do dynamic
initialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #16 from Jason Merrill ---
(In reply to Patrick Palka from comment #4)
> r13-6421 just makes us use mce_true and mce_uknown during trial constant
> evaluation of x's initialization, so my guess is before that commit the
> evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #15 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #12)
> The __uninitialized_default_n_1 specialization assumes that we can use
> std::fill_n to assign to objects outside their lifetime. I don't think
> that's vali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Jason Merrill changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #10 from Jason Merrill ---
(In reply to Jason Merrill from comment #9)
> Removing the maybe_constant_init from expand_default_init speeds up the
> testcase by more than 10x, but also regresses a bunch of testcases, so it's
> not that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115639
--- Comment #6 from Jason Merrill ---
(In reply to Patrick Palka from comment #5)
> ... and in particular if we have a cached mce_unknown call result it means
> the call isn't sensitive to mce, and so we can reuse later when evaluating
> the cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #9 from Jason Merrill ---
Removing the maybe_constant_init from expand_default_init speeds up the
testcase by more than 10x, but also regresses a bunch of testcases, so it's not
that simple.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115639
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
--- Comment #5 from Jason Merrill ---
Created attachment 61069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61069&action=edit
fix
This seems like the fix, can someone test it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119175
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119345
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119345
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=118698
Jason Merrill changed:
What|Removed |Added
CC||eczbek.void at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
Bug 107430 depends on bug 119129, which changed state.
Bug 119129 Summary: ICE: in keep_template_parm, at cp/pt.cc:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119129
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119129
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
Jason Merrill changed:
What|Removed |Added
Summary|[14/15 Regression] Compiler |[14 Regression] Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119175
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #16 from Jason Merrill ---
(In reply to Jason Merrill from comment #15)
> So I suspect we want to split the broader meaning out of tf_partial, so
> places like instantiate_template and normalize_concept_definition can choose
> it wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #15 from Jason Merrill ---
(In reply to Patrick Palka from comment #12)
> Substituting into seems like a partial
> substitution to me. If the lambda itself had any template parameters of its
> own, or autos, we wouldn't want to re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #11 from Jason Merrill ---
(In reply to Patrick Palka from comment #8)
> Started with r14-9938, though I bet before this commit it only accidentally
> worked.
This failure does seem to be strongly connected to that commit.
When nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117530
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652
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=118629
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=118629
--- Comment #8 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #7)
> both gcc and clang warn about it, but I think it shouldn't warn and have
> sizeof "foo" in that case.
It's not in scope yet for the trailing return-type accordi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117336
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 1515 matches
Mail list logo
