This is the mail archive of the 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

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 ( 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.


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



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