On Sun, Dec 13, 2015 at 10:59:11PM -0800, David Wohlferd wrote: > Is there a decision maker still teetering on the edge of making a call > here?
I think people are waiting for consensus, and we won't get consensus until there is a good solution, something that gives workable semantics (whatever those may be) and gives users a viable non-surprising way forward, keeping in mind they have code that needs to work with older compilers as well. > 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? That, and adding a memory clobber degrades performance for a lot of existing basic asm that does not expect the clobber, e.g. asm(""), asm("#"), asm("nop"), ... > > 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. This only works for some archs, for some ABIs, with some options. > 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. Yeah. Which is why I prefer basic asm to have the same semantics as extended asm without operands -- it does *now*, and has for many years. - - - There actually are three differences, it isn't *exactly* the same: 1) ia64 treats basic asm different, it always gives them stop bits; 2) basic asm does not use TARGET_MD_ASM_ADJUST, this is a problem; 3) basic asm does not need '%' (and for ASSEMBLER_DIALECT targets, '{' '|' '}') escaped with an extra '%'. This last point makes the "pretend basic asm never existed" option unworkable, there is quite some code that relies on it. Segher
