Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

On Fri, 17 Aug 2007, Paul E. McKenney wrote:

On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:

gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)

I had totally forgotten that I'd already filed that bug more
than six years ago until they just closed yours as a duplicate
of mine :)

Good luck in getting it fixed!

Well, just got done re-opening it for the third time. And a local
gcc community member advised me not to give up too easily. But I
must admit that I am impressed with the speed that it was identified
as duplicate.

Should be entertaining! ;-)

Right. ROTFL... volatile actually breaks atomic_t instead of making it
safe. x++ becomes a register load, increment and a register store. Without
volatile we can increment the memory directly. It seems that volatile
requires that the variable is loaded into a register first and then
operated upon. Understandable when you think about volatile being used to
access memory mapped I/O registers where a RMW operation could be
problematic.

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... gcc bugzilla bug #33102, for whatever that ends up being worth. ... I had totally forgotten that I'd already filed that bug more ... x++ becomes a register load, ... volatile we can increment the memory directly. ...
    (Linux-Kernel)
  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... than six years ago until they just closed yours as a duplicate ... x++ becomes a register load, ... It seems that volatile requires that the variable is loaded into a register first and then operated upon. ... Understandable when you think about volatile being used to access memory mapped I/O registers where a RMW operation could be problematic. ...
    (Linux-Kernel)
  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... It doesn't mean that (volatile int*) cast is bad, ... I would agree that fixing the compiler in this case would be a good thing, ... bad register allocation. ... still quite possible to find cases where it did some optimization (in this ...
    (Linux-Kernel)
  • Re: [patch] spinlocks: remove volatile
    ... I haven't been following this thread very closely but your assault on volatile is inappropriate. ... You cannot have an operand that describes a register class with a single member if that register is in the clobber list; there is simply no way to specify that an input operand is modified without explicitly specifying it as output. ... If all the output operands are for that purpose, ... volatile is _necessary_ for the asm to prevent the compiler from deleting it for this reason. ...
    (Linux-Kernel)
  • Re: When is "volatile" used instead of "lock" ?
    ... lock on the same reference you're ... volatile); but that's not its intention and it's certainly not documented as ... Also some may think that volatile implies a fence, which is not the case, it only tells the JIT to turn off some of the optimizations like register allocation and load/store reordering, but it doesn't prevent possible re-ordering and write buffering done by the CPU, note, that this is a non issue on X86 and X64 like CPU's, given the memory model enforced by the CLR, but it is an issue on IA64. ...
    (microsoft.public.dotnet.languages.csharp)