[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <43eccf425e36943ce0411c3b504b1de2@kernel.crashing.org>
Date: Thu, 16 Aug 2007 23:00:30 +0200
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Satyam Sharma <satyam@...radead.org>
Cc: Christoph Lameter <clameter@....com>, heiko.carstens@...ibm.com,
horms@...ge.net.au, Stefan Richter <stefanr@...6.in-berlin.de>,
Bill Fink <billfink@...dspring.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
netdev@...r.kernel.org, ak@...e.de, cfriesen@...tel.com,
rpjday@...dspring.com, jesper.juhl@...il.com,
linux-arch@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, zlynx@....org,
schwidefsky@...ibm.com, Chris Snook <csnook@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>, davem@...emloft.net,
Linus Torvalds <torvalds@...ux-foundation.org>,
wensong@...ux-vs.org, wjiang@...ilience.com
Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
> 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? GCC manual, section 6.1, "When
is a Volatile Object Accessed?" doesn't say anything of the
kind. PR33053 and some others.
> Honestly, given such confusion, and the propensity of the "volatile"
> type-qualifier keyword to be ill-defined (or at least poorly
> understood,
> often inconsistently implemented), I'd (again) express my opinion that
> it
> would be best to avoid its usage, given other alternatives do exist.
Yeah. Or we can have an email thread like this every time
someone proposes a patch that uses an atomic variable ;-)
Segher
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists