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