This is the mail archive of the
mailing list for the GCC project.
Re: [RFA:] fix PR55030, wrong code from __builtin_setjmp_receiver
Eric Botcazou <firstname.lastname@example.org> 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
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.