This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: basic asm and memory clobbers - Proposed solution


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]