On Thu, 19 Jul 2001, Linus Torvalds wrote:
> No. It's correct, because cpuid doesn't have any side effects (*), so we
> don't need to mark it volatile. gcc is free to remove it if nothing uses
> the outputs, for example. But gcc cannot (and generally does not) ignore
> outputs that _are_ specified.
My understanding was that eax, ... edx are declared as
local vars and so their values can't be used out of the current
function scope, even when they are defined in inline func. So, I
assume they can be optimized (the fact is that they are not used)
and may be gcc forgets them. True, may be the docs do not cover
such situations but my first thought was not to explain everything
with bugs.
> Now, adding the "volatile" doesn't really make things worse, and it will
> make gcc even more anal about optimizations than it normally is, which is
> probably why that also hides the gcc bug.
>
> Note that gcc having bus in the inline asm handling is nothing new. We've
> had that before, and I'm sure we'll have it again. Not very many people
> use them: the kernel tends to be the heaviest user of them (with libc
> probably a good second). Which is why bugs here often take time to get
> fixed. It doesn't help that the documentation has been quite bad, even
> misleading, at times.
Agreed. It seems I have to read more docs ...
> Linus
>
> (*) cpuid has the side effect of being a "synchronizing instruction", and
> as such you can use it for some SMP ordering things etc, but as it's one
> of the slowest such instructions nobody is really ever interested in using
> it that way, and it doesn't have any other "architecturally visible"
> effects that the compiler could care about.
Regards
-- Julian Anastasov <ja@ssi.bg>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/