This is the mail archive of the
mailing list for the GCC project.
Re: basic asm and memory clobbers - Proposed solution
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, Jeff Law <law at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, rth at redhat dot com, Paul_Koning at Dell dot com, jakub at redhat dot com, rth at gcc dot gnu dot org, pinskia at gcc dot gnu dot org, aph at redhat dot com, Ian Lance Taylor <iant at google dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Hans-Peter Nilsson <hp at bitrange dot com>, bernd dot edlinger at hotmail dot de
- Date: Tue, 1 Dec 2015 21:22:11 -0800
- Subject: Re: basic asm and memory clobbers - Proposed solution
- Authentication-results: sourceware.org; auth=none
- References: <56552209 dot 1020306 at LimeGreenSocks dot com> <56592801 dot 9010606 at LimeGreenSocks dot com> <565DC5F4 dot 6080804 at foss dot arm dot com> <565E1E37 dot 9080609 at LimeGreenSocks dot com> <alpine dot DEB dot 2 dot 10 dot 1512012323160 dot 12604 at digraph dot polyomino dot org dot uk> <565E6862 dot 7070401 at redhat dot com> <20151202035638 dot GA7321 at gate dot crashing dot org>
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.
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
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
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