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: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Andrew Haley <aph at redhat dot com>, Jeff Law <law at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, "rth at redhat dot com" <rth at redhat dot com>
- Cc: 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>, "Paul_Koning at Dell dot com" <Paul_Koning at Dell dot com>, "jakub at redhat dot com" <jakub at redhat dot com>, "rth at gcc dot gnu dot org" <rth at gcc dot gnu dot org>, "pinskia at gcc dot gnu dot org" <pinskia at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, Ian Lance Taylor <iant at google dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Hans-Peter Nilsson <hp at bitrange dot com>, bschmidt at redhat dot com
- Date: Sun, 13 Dec 2015 22:59: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> <566B4BA1 dot 8000509 at LimeGreenSocks dot com> <566BEE35 dot 6070804 at redhat dot com> <HE1PR07MB0905876DB6CE2AEBB578DBB6E4EC0 at HE1PR07MB0905 dot eurprd07 dot prod dot outlook dot com>
Is there a decision maker still teetering on the edge of making a call
here? Or have they all moved on and we are just talking among
ourselves? I keep worrying that if I don't reply, someone will swoop
in, read the last message in the thread, and charge off to make a
changes based on that. So...
On 12/13/2015 1:25 AM, Bernd Edlinger wrote:
That is also my preferred solution,
I'm really not sure what the point of doing the memory clobber is. Yes,
I see that it is easier to code than "clobber everything." And yes, it
might help with certain types of bugs for people who have or might
someday misuse asm.
But if we are trying to give users what they expect, shouldn't we be
doing the "clobber everything" Jeff suggested
(https://gcc.gnu.org/ml/gcc/2015-11/msg00081.html)? Surely that's the
"safest" answer, and it's as likely to be what people expect as anything
else. Adding the memory clobber will already break backward
compatibility and risk breaking existing code. Why do all that for half
a solution? Yes it's harder, but please don't tell me we plan to change
things yet again some day to do the rest?
> The rationale for this is: there are lots of ways to write basic asm
> statements, that may appear to work, if they clobber memory.
> because you can use all global values simply by name, users will
> expect that to be supported.
> people who know next
> to nothing about assembler will be encouraged to "fix" this warning in a
> part of the code which they probably do not understand at all.
So in the end, we are proposing a potentially breaking change, not
because we are violating a standard, not to give users what (some people
think) they expect, and not even because someone has actually reported a
problem. But because someone might use it wrong, and if we just point
the statement out to them, they might not know how to correct it.
That seems like a lot of risk for so very little gain.
And if we do end up changing this, using basic asm will become more
dangerous than ever. In addition to all the old problems (that will
still exist in earlier versions), now its behavior VARIES between
versions. Programmers who want specific behavior (rather than our
assumption-du-jour) will be forced to CHANGE THEIR CODE to account for
So my solution highlights at-risk statements that must be changed to use
extended asm. Your solution is that people will need to realize for
themselves that the statements must change to extended in order to work
the same way in newer versions, and then must find them all for themselves.
Further, if people (correctly) fix the warnings I'm proposing, then they
get correct behavior for all supported versions of the compiler. If
people do the nothing you are proposing, they may still have problems
even after the fix (if they assume registers get clobbered) or may have
new problems (performance or otherwise), and will still have problems
using any version of the compiler earlier than the one expected to be
released sometime late next year.
I prepared a patch for next stage1,
the details are still under discussion, but it is certainly do-able with
not too much effort.
I was unaware of this conversion. Unfortunate that you didn't think to
cc me on this, as there are several points I would have made regarding
the proposed code and doc changes. But mostly, I would have said what
Bernd Schmidt said: "I'm not sure there was any consensus in that other
thread" and "I think it would be best if we could deprecate basic asms
in functions, or at least warn about them in -Wall."
I have been talking myself blue in the fingers on this topic since early
November and I honestly don't know if I have convinced anyone of
anything. At this point, I really don't know what more I can say. It's
pretty much all in https://gcc.gnu.org/ml/gcc/2015-12/msg00092.html