https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #19 from Iain Sandoe ---
(In reply to Avi Kivity from comment #17)
> Please consider backporting
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576, this is a subtle code
> generation bug.
Noted, that a back-port is needed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #17 from Avi Kivity ---
This was apparently fixed by 58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f. At
least, I no longer observe copying of __old4 in gimple. Instead, I see
addresses taken, and if I squint I can see that object properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #16 from Avi Kivity ---
Bug hasn't fixed itself as of ccb9c7b129206209cfc315ab1a0432b5f517bdd9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #15 from Avi Kivity ---
I see that both sides of the assignment are created in flatten_await_stmt, case
case TARGET_EXPR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #14 from Avi Kivity ---
Do you confirm that my observation about the generated gimple corresponds to
the bug?
If so, is there a central point where this anonymous variables are named?
Perhaps we can breakpoint on D.2741 and see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2022-04-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #12 from Iain Sandoe ---
(In reply to Avi Kivity from comment #8)
> Hoping this is a duplicate of PR105287. Checking.
I doubt it, it would seem more likely that the temporary value representing the
non-coroutine lambda object is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #11 from Avi Kivity ---
Created attachment 52899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52899=edit
simple(r) reproducer
I was able to reduce it to something simple (102 lines), but I was only able to
verify that wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #10 from Avi Kivity ---
I have something like this:
│ 2680 future<> system_keyspace_make(distributed&
dist_db, distributed& dist_ss,
sharded& dist_gossiper, db::config& cfg) { │
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #9 from Avi Kivity ---
I think it makes it worse, now seeing similar crashes, but earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #8 from Avi Kivity ---
Hoping this is a duplicate of PR105287. Checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #7 from Avi Kivity ---
To give more context:
struct ._anon_973 D.2159793 [value-expr: frame_ptr->D.2159793_4_7];
struct lw_shared_ptr D.2159792 [value-expr: frame_ptr->D.2159792_4_7];
(I determined that _anon_973 is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #6 from Avi Kivity ---
Some more findings: if I replace the lambda (which is not a coroutine, but is
contained in a coroutine lambda) with an equivalent struct, the problem goes
away, both at runtime and in terms of an __old4 copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #5 from Avi Kivity ---
Can you confirm my suspicion about the copying of __old4 in gimple? If that's
the culprit I believe I can mechanically reduce the reproducer to something
easily manageable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #4 from Iain Sandoe ---
I'm guessing that a reproducer is going to be hard to arrange (from the
"complex piece of code") even though the failing point is well-defined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #3 from Avi Kivity ---
I see this alleged copy in gcc 10.2.1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #2 from Avi Kivity ---
I see it in 006t.gimple too:
try
{
_50 = frame_ptr->__closure;
_51 = _50->__this;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #1 from Avi Kivity ---
I randomly looked at 023t.ssa (mainly because I recognized the acronym).
_45 = frame_ptr_182(D)->__closure;
_46 = _45->__this;
frame_ptr_182(D)->D.2159984_4_7 =
19 matches
Mail list logo
