[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708180556330.3666@enigma.security.iitk.ac.in>
Date: Sat, 18 Aug 2007 07:26:30 +0530 (IST)
From: Satyam Sharma <satyam@...radead.org>
To: Segher Boessenkool <segher@...nel.crashing.org>
cc: Christoph Lameter <clameter@....com>,
Paul Mackerras <paulus@...ba.org>, heiko.carstens@...ibm.com,
horms@...ge.net.au, Stefan Richter <stefanr@...6.in-berlin.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
ak@...e.de, cfriesen@...tel.com, rpjday@...dspring.com,
Netdev <netdev@...r.kernel.org>, jesper.juhl@...il.com,
linux-arch@...r.kernel.org, zlynx@....org,
Andrew Morton <akpm@...ux-foundation.org>,
schwidefsky@...ibm.com, Chris Snook <csnook@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
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
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > atomic_dec() writes
> > > > > to memory, so it _does_ have "volatile semantics", implicitly, as
> > > > > long as the compiler cannot optimise the atomic variable away
> > > > > completely -- any store counts as a side effect.
> > > >
> > > > I don't think an atomic_dec() implemented as an inline "asm volatile"
> > > > or one that uses a "forget" macro would have the same re-ordering
> > > > guarantees as an atomic_dec() that uses a volatile access cast.
> > >
> > > The "asm volatile" implementation does have exactly the same
> > > reordering guarantees as the "volatile cast" thing,
> >
> > I don't think so.
>
> "asm volatile" creates a side effect.
Yeah.
> Side effects aren't
> allowed to be reordered wrt sequence points.
Yeah.
> This is exactly
> the same reason as why "volatile accesses" cannot be reordered.
No, the code in that sub-thread I earlier pointed you at *WAS* written
such that there was a sequence point after all the uses of that volatile
access cast macro, and _therefore_ we were safe from re-ordering
(behaviour guaranteed by the C standard).
But you seem to be missing the simple and basic fact that:
(something_that_has_side_effects || statement)
!= something_that_is_a_sequence_point
Now, one cannot fantasize that "volatile asms" are also sequence points.
In fact such an argument would be sadly mistaken, because "sequence
points" are defined by the C standard and it'd be horribly wrong to
even _try_ claiming that the C standard knows about "volatile asms".
> > > if that is
> > > implemented by GCC in the "obvious" way. Even a "plain" asm()
> > > will do the same.
> >
> > Read the relevant GCC documentation.
>
> I did, yes.
No, you didn't read:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
Read the bit about the need for artificial dependencies, and the example
given there:
asm volatile("mtfsf 255,%0" : : "f" (fpenv));
sum = x + y;
The docs explicitly say the addition can be moved before the "volatile
asm". Hopefully, as you know, (x + y) is an C "expression" and hence
a "sequence point" as defined by the standard. So the "volatile asm"
should've happened before it, right? Wrong.
I know there is also stuff written about "side-effects" there which
_could_ give the same semantic w.r.t. sequence points as the volatile
access casts, but hey, it's GCC's own documentation, you obviously can't
find fault with _me_ if there's wrong stuff written in there. Say that
to GCC ...
See, "volatile" C keyword, for all it's ill-definition and dodgy
semantics, is still at least given somewhat of a treatment in the C
standard (whose quality is ... ummm, sadly not always good and clear,
but unsurprisingly, still about 5,482 orders-of-magnitude times
better than GCC docs). Semantics of "volatile" as applies to inline
asm, OTOH? You're completely relying on the compiler for that ...
> > [ of course, if the (latest) GCC documentation is *yet again*
> > wrong, then alright, not much I can do about it, is there. ]
>
> There was (and is) nothing wrong about the "+m" documentation, if
> that is what you are talking about. It could be extended now, to
> allow "+m" -- but that takes more than just "fixing" the documentation.
No, there was (and is) _everything_ wrong about the "+" documentation as
applies to memory-constrained operands. I don't give a whit if it's
some workaround in their gimplifier, or the other, that makes it possible
to use "+m" (like the current kernel code does). The docs suggest
otherwise, so there's obviously a clear disconnect between the docs and
actual GCC behaviour.
[ You seem to often take issue with _amazingly_ petty and pedantic things,
by the way :-) ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists