>
>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.
Imagine if the storage address involved was an I/O register which was
memory mapped. An arbitrary storage of data might have disasterous
effects.
john alvord
-
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/