Re: [patch] compiler: clarify ACCESS_ONCE() relies on compiler implementation

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, Apr 3, 2013 at 7:18 PM, David Rientjes <rientjes@google.com> wrote:
>
> Would you convert the definition of ACCESS_ONCE() to use the resulting
> feature from the gcc folks that would actually guarantee it in the
> compiler-gcc.h files?

So I wouldn't object for any other reason than the fact that it makes
me feel like I'm helping somebody screw up "volatile", and then we
would help cover up that serious compiler quality regression.

So I do repeat: what kind of messed-up compiler could *possibly* do
the wrong thing for our current use of accessing a volatile pointer,
and not consider that a compiler bug? Why should be support such a
fundamentally broken agenda?

Yes, yes, I know all about how compiler people will talk about "access
to volatile pointer" vs "actual volatile *object*", as if that made
things fundamentally different. I personally don't think it makes any
difference what-so-ever, and a quality compiler shouldn't either. Yes,
the compiler can get confused about aliasing, but hey, if it doesn't
keep track of the volatile status of some pointer access, then it's
going to get confused about aliasing elsewhere when it passes down
pointer to an actual volatile object in a union or whatever. So a good
C compiler really wants to get that kind of thing right *anyway*.

IOW, I'm not seeing a huge upside, and I *am* seeing downsides.  Why
should we encourage bad C implementations? If the compiler people
understand that threading (as well as just IO accesses) do actually
need the whole "access once" semantics, and have support for that in
their compiler anyway, why aren't they just turning "volatile" into
that?

IOW, my argument is that a *good* C compiler writer would acknowledge that:

  "Yes, the language specs may allow me to quibble about what the
meaning of the word "object" is, but I also realize that people who do
threading and IO accesses need a way to specify "access once" through
a pointer without any regard to what the "underlying object" -
whatever that is - is, so I might as well interpret the meaning of
"object" to include the known needed semantics of access through a
pointer, and turn it into this internal interface that I have to
expose *anyway*".

So instead of encouraging people to rely on some strange
compiler-dependent crap, why not just admit that the C standard
*could* also be read the way the language was clearly meant to be
read, without any stupid quibbling? And instead of the
compiler-specific thing, say "Our compiler is a *good* compiler, and
we took the C standard language and read it in the most useful way
possible, and made our compiler *better*".

IOW, instead of going down the whole idiotic language-lawyer dead end,
just DTRT. What is the advantage to *anybody* - C compiler writers
included - in making "volatile" less useful, and blathering about bad
specifications.

This is my "quality of implementation" argument. A C compiler
shouldn't try to screw over its users. If there is some undefined
corner-case, try to define it as usefully as possible. And for
"volatile pointer accesses", there really are clear and unambiguous
good and useful interpretations, which just say "we consider the
volatile pointer access to be a volatile object, and we won't be
quibbling and trying to argue about the meaning of "object"".

                     Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>