basic asm and memory clobbers - Proposed solution

David Wohlferd dw@LimeGreenSocks.com
Wed Dec 2 05:22:00 GMT 2015


On 12/1/2015 7:56 PM, Segher Boessenkool wrote:
> On Tue, Dec 01, 2015 at 08:41:22PM -0700, Jeff Law wrote:
>> Isn't "asm" conditionally supported for ISO C++?  In which case it's not
>> mandatory and semantics are implementation defined.
> Yes.
>
>> My strong preference is still to document the desired semantics for GCC
>> and treat anything that does not adhere to those semantics as a bug.
> I agree, but I think the semantics should be what they currently are.
> If we want a "clobbers everything" version we could make a new syntax
> for that, so that not all current asm-without-operands has to pay the
> hefty price.
>
>> I think a non-default warning is fine.  A default warning (or
>> -Wall/-Westra) is probably undesirable, though I'm still willing to be
>> convinced either way on that.
> I don't think the warning is a good idea until we have decided what
> direction we want this to go in.

If we are headed toward removing "basic asm in a function," then the 
warning (combined with deprecation in the docs) is a logical first 
step.  It lets people find and begin to fix this code with only a 
trivial change to v6.  But if that's not where we're headed, I don't see 
who would ever use it.

I also agree that we shouldn't change the semantics of basic asm to 
"clobber everything."  The coding for the change is not immediately 
clear, the backward compatibility issues are a challenge, and future 
moves to extended become much more complicated.  I understand that 
clobbering may fix problems (that no one is asking us to fix), but at a 
performance, maintenance or 'new bugs' price that I can't see how to 
justify.

I think requiring people to specify what their asm affects (aka extended 
asm) is the right answer.  But if removing "basic asm in a function," is 
not the direction we want to go, my vote is to just doc the current 
behavior.

dw



More information about the Gcc mailing list