Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures | Date | Sat, 18 Aug 2007 02:04:35 +0200 |
| |
>>>> 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. Side effects aren't allowed to be reordered wrt sequence points. This is exactly the same reason as why "volatile accesses" cannot be reordered.
>> 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.
> [ 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.
Segher
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |