On Mon, 19 Nov 2001, Alan Cox wrote:
>
> You can in theory get even stranger effects. Consider
>
> if(!(flag&4))
> {
> blahblah++;
> flag|=4;
> }
>
> The compiler is completely at liberty to turn that into
>
> test bit 2
> jz 1f
> inc blahblah
> add #4, flag
> 1f:
That's fine - if you have two threads modifying the same variable at the
same time, you need to lock it.
That's not the case under discussion.
The case under discussion is gcc writing back values to a variable that
NEVER HAD ANY VALIDITY, even in the single-threaded case. And it _is_
single-threaded at that point, you only have other users that test the
value, not change it.
That's not an optimization, that's just plain broken. It breaks even
user-level applications that use sigatomic_t.
And note how gcc doesn't actually do it. I'm not saying that gcc is broken
- I' saying that gcc is NOT broken, and we depend on it being not broken.
Linus
-
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/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:20 EST