> Honza? Do you assure me that? In case you don't, could you suggest
> another way besides volatile and spinlocks around the access to the
> variable to avoid gcc to get confused?
Looking at the code, it really looks as perfect candidate for volatile.
GCC has definitly right to assume that the memory location won't change
and use it for optimization. On the other hand, from usual usage of
time I guess gcc won't be able to do so, at least not today.
Basically most optimizations comes from that compiler recognizes that
value is equivalent to something (constant) at given code path and
promotes it futher.
So it is probably up to kernel folks if you want to follow C standard
and blame gcc developers for breaking it, or stay in the unsafe ground
and fix kernel each time gcc will introduce new nasty optimizations.
This may become tricky later - for instance as making kernel codebase
-fstrict-aliasing ready.
Honza
-
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 : Tue Jul 31 2001 - 21:00:29 EST