Re: [PATCH 24/24] document volatile atomic_read() behavior

[Chris Snook <csnook@redhat.com>]

Segher Boessenkool wrote:
> > Historically this has been
> > +accomplished by declaring the counter itself to be volatile, but the
> > +ambiguity of the C standard on the semantics of volatile make this 
> > practice
> > +vulnerable to overly creative interpretation by compilers.
>
> It's even worse when accessing through a volatile casted pointer;
> see for example the recent(*) GCC bugs in that area.
>
> (*) Well, not _all_ that recent.  No one should be using the 3.x
> series anymore, right?
>
> > Explicit
> > +casting in atomic_read() ensures consistent behavior across 
> > architectures
> > +and compilers.
>
> Even modulo compiler bugs, what makes you believe that?

When you declare a variable volatile, you don't actually tell the compiler where 
you want to override its default optimization behavior, giving it some freedom 
to guess your intentions incorrectly.  When you put the cast on the data access 
itself, there is no question about precisely where in the code you want to 
override the compiler's default optimization behavior.  If the compiler doesn't 
do what you want with a volatile declaration, it might have a plausible excuse 
in the ambiguity of the C standard.  If the compiler doesn't do what you want in 
a cast specific to a single dereference, it's just plain broken.  We try to be 
compatible with plausibly correct compilers, but if they're completely broken, 
we're screwed no matter what.

	-- Chris
-
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/