Re: basic asm and memory clobbers - Proposed solution
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
Re: basic asm and memory clobbers - Proposed solution
On 13/12/15 06:15, David Wohlferd wrote: > > However breakage and performance issues can still result solely from > adding memory clobbers. Breakage? Really? > And as I mentioned, "just memory clobber" may > not be the behavior people expect. And if we aren't solving that, might > there be a second update later to add registers? Talk about confusing > semantics... No, there will not be. >> It allows basic asm to be used in a sensible way by pushing and >> popping all used registers. > > If I were using basic asm, this would indeed seem like a sensible approach. > > However, it is not the most efficient. If I can clobber registers, > push/pop are just wasted cycles. This just seems like another argument > for deprecating basic asm and pushing people to extended. Yes. I am not arguing against deprecation. We should do that. > -- > Imagine for a moment: > > If the only way right now to do inline asm in gcc was extended, and I > proposed adding basic, how could I justify this 'new' feature? You couldn't. It's legacy-only. > Contra-wise, what if starting today all new inline asm were written > using extended? How would that be a bad thing? It would not. You are arguing against a position that no-one holds. > Which means (to me), the only real justification for the continued > existence of basic asm is backward compatibility. Which makes the > arguments for changing its behavior (whether a little or a lot) > kinda weird. No, it does not make them weird at all. All it does is make an existing feature safer. > I still vote for doing everything we can think of to discourage people > from using basic and begin using extended: > > - Change the docs to flat out deprecate basic (excluding top-level). OK. > - Add the warning so people's integrated dev environments will show the > suspect lines. OK, if the warning is optional. > - Make the warning a default, but overridable (-Wno-only-top-basic-asm), > so people who HAVE to support the old syntax still can. That's a little more dubious. Maybe. > - Make sure the docs for the warning describe (link to?) how to change > asm from basic to extended and why. > - Any bugs people report or posts people make involving basic asm get > resolved as 'Try it with extended.' > I'm just afraid that instead of pursuing any of these solutions, we > are going to pursue Solution #0: Do nothing. A rather unsatisfying > outcome after all this effort. You can't simultaenously insist that it gets fixed the way you want and complain about the difficulty of reaching consensus, y'know. :-) A basic asm which clobbers memory and saves registers has no correctness problems whatsoever. There is no reason that people should not use it, and continue to use it if it suits them. Andrew.
Re: C++ compilers
To whom it may concern: My name is Brett Searles and I am the Vice President of the local user group, The Northwest C++ Users Group. Even though we are closely affiliated with Microsoft, since we have our meetings there, we are also interested in educating the community about other C++ Compiler Front-ends. So I am reaching out for 3 reasons: 1) Want to work with GCC to educate the community 2) Want to put out surveys for GCC 3) NWCPP is also closely related to CppCon, an annual conference that the ISO committee holds every September, so that NWCPP can hold forums for different compiler front-ends. Please review our website and let me know who to discuss these items. The website is http://nwcpp.org/ . Thanks, Brett
Question on visible scope in template declaration
Hello list,
The following code is rejected by GCC but accepted by Clang:
template
auto f(T v) -> decltype(g(v));
int g(int) { return 0; }
template
auto f(T v) -> decltype(g(v))
{
return g(v) + 1;
}
int main()
{
return f(0);
}
Error message at http://ideone.com/Vn79Hm.
Basically the problem comes down to which is the visible scope in that
trailing return type decltype(g(v)), where GCC uses the point of
declaration but Clang uses the point of definition. g is a dependent
name here, and the standard says "template definition context" should be
used; but I am not very sure about the wording. I suspect this to be a
GCC bug, but not sure, so asking here first.
--
Carl Lei (XeCycle)
Department of Physics and Astronomy, SJTU
Re: Question on visible scope in template declaration
On Mon, Dec 14, 2015 at 7:01 PM, Carl Lei wrote:
> Hello list,
>
> The following code is rejected by GCC but accepted by Clang:
>
> template
> auto f(T v) -> decltype(g(v));
>
> int g(int) { return 0; }
>
> template
> auto f(T v) -> decltype(g(v))
> {
> return g(v) + 1;
> }
>
> int main()
> {
> return f(0);
> }
>
> Error message at http://ideone.com/Vn79Hm.
>
> Basically the problem comes down to which is the visible scope in that
> trailing return type decltype(g(v)), where GCC uses the point of declaration
> but Clang uses the point of definition. g is a dependent name here, and the
> standard says "template definition context" should be used; but I am not
> very sure about the wording. I suspect this to be a GCC bug, but not sure,
> so asking here first.
There is also argument dependent lookup.
Thanks,
Andrew Pinski
>
> --
> Carl Lei (XeCycle)
> Department of Physics and Astronomy, SJTU
Re: Question on visible scope in template declaration
在 12/15/15 11:09, Andrew Pinski 写道:
On Mon, Dec 14, 2015 at 7:01 PM, Carl Lei wrote:
Hello list,
The following code is rejected by GCC but accepted by Clang:
template
auto f(T v) -> decltype(g(v));
int g(int) { return 0; }
template
auto f(T v) -> decltype(g(v))
{
return g(v) + 1;
}
int main()
{
return f(0);
}
Error message at http://ideone.com/Vn79Hm.
Basically the problem comes down to which is the visible scope in that
trailing return type decltype(g(v)), where GCC uses the point of declaration
but Clang uses the point of definition. g is a dependent name here, and the
standard says "template definition context" should be used; but I am not
very sure about the wording. I suspect this to be a GCC bug, but not sure,
so asking here first.
There is also argument dependent lookup.
Yes, I am aware of that, and I worked around this problem by adding an
empty struct as a tag for ADL to my function signatures. But whether g
should be found in the first phase before ADL is another question.
--
Carl Lei (XeCycle)
Department of Physics and Astronomy, SJTU
