Created attachment 50729 [details] Reproducer for the bug Hi. The attached example produce a segfault when trying to compile code using inline assembly. Thanks.
Created attachment 50730 [details] Fixed reproducer
Created attachment 50731 [details] Working code So, the segfault seems to happen when creating the variable after creating the extended asm expression. Here's a working version of the code.
I'll take a look.
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 tries to access the replayed variable (which wasn't replayed yet because it was created after the asm). * Segfault (the rest is not executed, but is shown to explain what's happening) * The variable is replayed (too late because it was NULL when accessed by the asm). Again it's to be verified, and I'm not sure what should be the solution to this problem because the mementos are replayed in the order they were created.
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 everywhere, so that seems very invasive. Do you think there's a better solution?
Leaving to David..
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 intermediate memento that does the work of add_output_operand (and most likely the other actions like add_input_operand). It works since this memento will necessarily be created after both the asm and the variable and thus, both will have been replayed when it's time to replay the new 'add_output_operand' memento.