Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool <hidden>
Date: 2007-08-17 22:45:29
Also in:
lkml, netdev
From: Segher Boessenkool <hidden>
Date: 2007-08-17 22:45:29
Also in:
lkml, netdev
quoted
quoted
Here, I should obviously admit that the semantics of *(volatile int *)& aren't any neater or well-defined in the _language standard_ at all. The standard does say (verbatim) "precisely what constitutes as access to object of volatile-qualified type is implementation-defined", but GCC does help us out here by doing the right thing.Where do you get that idea?Try a testcase (experimentally verify).
That doesn't prove anything. Experiments can only disprove things.
quoted
GCC manual, section 6.1, "When is a Volatile Object Accessed?" doesn't say anything of the kind.True, "implementation-defined" as per the C standard _is_ supposed to mean "unspecified behaviour where each implementation documents how the choice is made". So ok, probably GCC isn't "documenting" this implementation-defined behaviour which it is supposed to, but can't really fault them much for this, probably.
GCC _is_ documenting this, namely in this section 6.1. It doesn't mention volatile-casted stuff. Draw your own conclusions. Segher