https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Sam James changed:
What|Removed |Added
See Also||https://bugs.kde.org/show_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #28 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a1855a3e0bcf0f94bc9fa421ccc9ebd0565c62cd
commit r15-7503-ga1855a3e0bcf0f94bc9fa421ccc9ebd0565c62cd
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #27 from Sam James ---
I'll test with the option re-enabled to confirm but I'm sure it is. I'll only
comment/reopen if problems persist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #25 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
commit r15-7481-g0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
Author: Jason Merrill
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #24 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #23)
> Or could we try to walk all the cleanups queued at the end of the range-for
> and pushdecl any temporaries mentioned in there if they don't have DECL_NAME
> yet?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
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=118574
--- Comment #23 from Jakub Jelinek ---
Or could we try to walk all the cleanups queued at the end of the range-for and
pushdecl any temporaries mentioned in there if they don't have DECL_NAME yet?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #22 from Jason Merrill ---
We might change the P2718 strategy to use set_up_extended_ref_temp for all
temps in the range_for initializer, rather than none.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #21 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #20)
> Note, even just
> But in the range-for case, the lifetime of those temporaries doesn't end at
> the end of the statement but is until the end of the range for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #20 from Jakub Jelinek ---
Note, even just
foo ({});
outside of range-for has its temporaries without pushdecl.
const struct D D.2692;
...
try
{
D::D (&D.2692);
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #19 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #17)
> Note, even the D {} temporary goes into function local vars rather than in
> the narrower scope.
hmm. This might be an underlying problem, the coroutines code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #18 from Jason Merrill ---
Before my PR118491 commit, this temporary was added to the frame, apparently
that simple change was inadequate to deal with this category of issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #17 from Jakub Jelinek ---
Note, even the D {} temporary goes into function local vars rather than in the
narrower scope.
While for the -std=c++20 case the temporary is created and pushdecl called on
it
#0 pushdecl (decl=, hiding=fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #16 from Iain Sandoe ---
I wonder if this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94897 is of any
relevance?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #15 from Jakub Jelinek ---
BTW, it might be also interesting to test behavior of the other temporaries
extended newly in the range for, so say something like
#include
[[gnu::noipa]] void
baz (int *)
{
}
struct D {
D () : d (new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #14 from Jakub Jelinek ---
Looking at gimple with co_await B{20}; line commented out, the difference
-fno-range-for-ext-temps vs -frange-for-ext-temps is
@@ -77,7 +77,6 @@ void A::~A (struct A * const this)
void bar ()
{
+ st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #12 from Jakub Jelinek ---
Finally testcase with only :
#include
struct A {
const char **a = nullptr;
int n = 0;
void push_back (const char *x) { if (!a) a = new const char *[2]; a[n++] = x;
}
const char **begin () const {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #10 from Jakub Jelinek ---
No iostream/string:
#include
#include
#include
#include
using namespace std::chrono_literals;
struct TimerAwaiter {
std::chrono::milliseconds duration;
bool await_ready() const noexcept { retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #11 from Jakub Jelinek ---
No thread/chrono:
#include
#include
#include
#include
struct TimerAwaiter {
long ns;
bool await_ready() const noexcept { return false; }
void await_suspend(std::coroutine_handle<> h) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #9 from Sam James ---
(In reply to Jakub Jelinek from comment #7)
> Can you bisect to one TU using -f{,no-}range-for-ext-temps?
I started last night, but the crashers are plugins which makes it a nuisance.
I'll work more on it if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #8 from Jakub Jelinek ---
In the rhbz bug Alessandro Astone came up with:
#include
#include
#include
#include
#include
#include
using namespace std::chrono_literals;
struct TimerAwaiter {
std::chrono::milliseconds duratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #7 from Jakub Jelinek ---
(In reply to Sam James from comment #5)
> Unfortunately, it looks like the fixes weren't enough and the crashes are
> back when dropping -fno-range-for-ext-temps.
Can you bisect to one TU using -f{,no-}rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #6 from Iain Sandoe ---
(In reply to Sam James from comment #5)
> Unfortunately, it looks like the fixes weren't enough and the crashes are
> back when dropping -fno-range-for-ext-temps.
ack
does https://gcc.gnu.org/bugzilla/show_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #5 from Sam James ---
Unfortunately, it looks like the fixes weren't enough and the crashes are back
when dropping -fno-range-for-ext-temps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #4 from Sam James ---
-fno-range-for-ext-temps seems to have helped with an older trunk (from before
the weekend). I'll try Jason's fixes now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Bug 118574 depends on bug 116914, which changed state.
Bug 116914 Summary: [15 regression] ICE when building plasma-nm-6.1.5
(gimplify_var_or_parm_decl, at gimplify.cc:3309) with -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #2 from Sam James ---
(In reply to Jakub Jelinek from comment #1)
> Is KDE Plasma built with -std=gnu++20 or -std=gnu++17?
-std=gnu++20
> Perhaps as a workaround -fno-range-for-ext-temps option could help.
> If it is built with -st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
32 matches
Mail list logo
