basic asm and memory clobbers - Proposed solution

[David Wohlferd]

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 
this variability.

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.
>>
>> See https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00938.html

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

FWIW.

dw