https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
--- Comment #7 from Antoni ---
Since then, I found a workaround to fix the similar segfault in my other
feature.
It might work for solving this and goes like this:
instead of trying to access the rvalue when first replaying the asm, create an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
--- Comment #5 from Antoni ---
I can confirm that the problem is indeed what I described in my previous post.
One solution would be to check if the rvalue was replayed (and if not, replay
it now), but that involves adding this check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
--- Comment #4 from Antoni ---
I just had a similar issue when developing a new feature for libgccjit and it
might be the same problem. If it is (I haven't checked in this case), here's
what's happening:
* The asm is replayed.
* The asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
--- Comment #2 from Antoni ---
Created attachment 50731
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50731=edit
Working code
So, the segfault seems to happen when creating the variable after creating the
extended asm expression.
Here's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
Antoni changed:
What|Removed |Added
Attachment #50729|0 |1
is obsolete|