[PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

J.W. Jagersma jwjagersma@gmail.com
Sun Nov 15 13:00:49 GMT 2020


On 2020-11-12 16:51, Jeff Law wrote:
> 
> On 3/11/20 6:38 PM, J.W. Jagersma via Gcc-patches wrote:
>> The following patch extends the generation of exception handling
>> information, so that it is possible to catch exceptions thrown from
>> volatile asm statements, when -fnon-call-exceptions is enabled.  Parts
>> of the gcc code already suggested this should be possible, but it was
>> never fully implemented.
>>
>> Two new test cases are added.  The target-dependent test should pass on
>> platforms where throwing from a signal handler is allowed.  The only
>> platform I am aware of where that is the case is *-linux-gnu, so it is
>> set to XFAIL on all others.
>>
>> gcc/
>> 2020-03-11  Jan W. Jagersma  <jwjagersma@gmail.com>
>>
>> 	PR inline-asm/93981
>> 	* tree-cfg.c (make_edges_bb): Make EH edges for GIMPLE_ASM.
>> 	* tree-eh.c (lower_eh_constructs_2): Add case for GIMPLE_ASM.
>> 	Assign register output operands to temporaries.
>> 	* doc/extend.texi: Document that volatile asms can now throw.
>>
>> gcc/testsuite/
>> 2020-03-11  Jan W. Jagersma  <jwjagersma@gmail.com>
>>
>> 	PR inline-asm/93981
>> 	* g++.target/i386/pr93981.C: New test.
>> 	* g++.dg/eh/pr93981.C: New test.
> 
> Is this the final version of the patch?  Do we have agreement on the
> sematics for output operands, particularly memory operands?  The last
> few messages in the March thread lead me to believe that's still not
> settled.
> 
> 
> Jeff

Hi Jeff,

>From what I remember, no consensus was reached.  The discussion didn't seem
to be going anywhere, and I had found a suitable workaround, so the issue
dropped off my radar.  However this workaround now turned out to be somewhat
fragile so I do hope to see this implemented in gcc someday.

I'll have to check but I do think this is the "best" version I have of this
patch.  In my most recent branch here I changed all memory operands to inout,
but I recall there being some problem with this.  Anyway, as I think Richard
said (most of this goes over my head), I think this is best left up to the
user.  If one expects their asm to throw they would also be smart enough to
use the '+' modifier so that previous assignments are not optimized out.


More information about the Gcc-patches mailing list