Re: [RFA:] fix PR55030, wrong code from __builtin_setjmp_receiver

[Richard Sandiford <rdsandiford at googlemail dot com>]

Eric Botcazou <ebotcazou@adacore.com> writes:
>> I strongly disagree with this.  Outputs and clobbers have significant
>> meaning even on volatile asms, asm volatile doesn't mean all registers and
>> all memory are supposed to be considered clobbered.  For memory you have
>> "memory" clobber for that, for registers it is users responsibility to
>> describe exactly what changes, either in clobbers or in outputs.
>> The difference between non-volatile and volatile asm is, as the
>> documentation states:
>> 
>> The `volatile' keyword indicates that the instruction has important
>> side-effects.  GCC will not delete a volatile `asm' if it is reachable.
>> 
>> Volatile asm acts as an optimization barrier to some extent, but it really
>> can't modify registers or memory that aren't described as modified in the
>> asm pattern.  The important side-effects are of some other kind than
>> modifying registers or memory visible from the current function.
>> Ditto for UNSPEC_VOLATILE.
>
> Well, the last sentence would essentially void the entire argument I
> think.  It's well established in the RTL middle-end that
> UNSPEC_VOLATILE can do pretty much everything behind the back of the
> compiler.

As always when jumping in the middle of thread, I might well be missing
the point sorry, but this sounded a bit extreme if taken literally.
An UNSPEC_VOLATILE doesn't in itself force the function to save all
call-saved registers, so an UNSPEC_VOLATILE that modifies those registers
behind the back of the compiler would lead to us generating wrong code.
And I thought UNSPEC_VOLATILEs that also clobber visible memory in an
unpredictable way had to have something like (clobber (mem:BLK (scratch))).

I thought Jakub's "the important side-effects are of some other
kind than modifying registers or memory visible from the current
function" applied to UNSPEC_VOLATILE too.

Richard