On Mon, 13 Aug 2007, Chris Snook wrote:
> Paul Mackerras wrote:
> > Chris Snook writes:
> > > I'll do this for the whole patchset. Stay tuned for the resubmit.
> >
> > Could you incorporate Segher's patch to turn atomic_{read,set} into
> > asm on powerpc? Segher claims that using asm is really t
Paul Mackerras wrote:
Chris Snook writes:
I'll do this for the whole patchset. Stay tuned for the resubmit.
Could you incorporate Segher's patch to turn atomic_{read,set} into
asm on powerpc? Segher claims that using asm is really the only
reliable way to ensure that gcc does what we want,
Chris Snook writes:
> I'll do this for the whole patchset. Stay tuned for the resubmit.
Could you incorporate Segher's patch to turn atomic_{read,set} into
asm on powerpc? Segher claims that using asm is really the only
reliable way to ensure that gcc does what we want, and he seems to
have a p
> Here are the functions in which they occur in the object file. You
> may have to chase down some inlining to find the function that
> actually uses atomic_*().
Ignore this ... Andreas' patch was only two lines so I
thought I'd "save time" by just hand-editing the source over
on my build machine.
Linus Torvalds wrote:
On Fri, 10 Aug 2007, Luck, Tony wrote:
Here are the functions in which they occur in the object file. You
may have to chase down some inlining to find the function that
actually uses atomic_*().
Could you just make the "atomic_read()" and "atomic_set()" functions be
inl
On Fri, 10 Aug 2007, Luck, Tony wrote:
>
> Here are the functions in which they occur in the object file. You
> may have to chase down some inlining to find the function that
> actually uses atomic_*().
Could you just make the "atomic_read()" and "atomic_set()" functions be
inline functions in
> Possibly. Either that or we've uncovered some latent bugs. Maybe a
> combination of the two. Can you list those 19 changes so we can
evaluate them?
Here are the functions in which they occur in the object file. You
may have to chase down some inlining to find the function that
actually uses
Luck, Tony wrote:
Use atomic64_read to read an atomic64_t.
Thanks Andreas!
Chris: This bug is why the 8-byte loads got changed to 4-byte + sign-extend
by your change to atomic_read().
I figured as much. Thanks for confirming this.
With this applied together with shuffling the volatile fro
> Use atomic64_read to read an atomic64_t.
Thanks Andreas!
Chris: This bug is why the 8-byte loads got changed to 4-byte + sign-extend
by your change to atomic_read().
With this applied together with shuffling the volatile from the
declaration to the usage (in both atomic_read() and atomic_set()
"Luck, Tony" <[EMAIL PROTECTED]> writes:
>> That's distressing. I'm about to resubmit with a volatile cast in
>> atomic_set as well, since people expect that behavior and I've been
>> shown a legitimate case where it could matter. Does the assembly look
>> right with that cast in atomic_set()
> That's distressing. I'm about to resubmit with a volatile cast in
> atomic_set as well, since people expect that behavior and I've been
> shown a legitimate case where it could matter. Does the assembly look
> right with that cast in atomic_set() as well?
No. With the casts to volatile in
Luck, Tony wrote:
+#define atomic_read(v) (*(volatile __s32 *)&(v)->counter)
+#define atomic64_read(v) (*(volatile __s64 *)&(v)->counter)
#define atomic_set(v,i)(((v)->counter) = (i))
#define atomic64_set(v,i) (((v)->counter) = (i))
Losing the volatile fro
> +#define atomic_read(v) (*(volatile __s32 *)&(v)->counter)
> +#define atomic64_read(v) (*(volatile __s64 *)&(v)->counter)
>
> #define atomic_set(v,i) (((v)->counter) = (i))
> #define atomic64_set(v,i)(((v)->counter) = (i))
Losing the volatile from the "set"
From: Chris Snook <[EMAIL PROTECTED]>
Purify volatile use for atomic[64]_t on ia64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc2-orig/include/asm-ia64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-ia64/atomic.h 2007-08-09 06:53:48.
14 matches
Mail list logo
