Oleksandr Redchuk wrote:
2007/9/2, David Brown [EMAIL PROTECTED]:
Similarly, if you have multiple objects being constructed or
destructed, their ordering is *not* guaranteed by the compiler
AFAIR, this order guaranteed for objects in block of code and for
objects in file - in order of
David Brown wrote:
I believe [the compiler] can [change order of ... volatile objects
access].
Obviously it is only legal if such moves do not affect the volatile
accesses themselves. Perhaps someone here who has a better knowledge of
the standards ...
I wouldn't claim better knowledge, but
2007/9/2, David Brown [EMAIL PROTECTED]:
Similarly, if you have multiple objects being constructed or
destructed, their ordering is *not* guaranteed by the compiler
AFAIR, this order guaranteed for objects in block of code and for
objects in file - in order of definitions, but not guaranteed
Oleksandr Redchuk wrote:
Is this overoptimization bug or not?
I'm not really an expert in this, but I think it is a valid
optimisation. Access to SREG is volatile, so the compiler cannot change
or re-order accesses, but it is free to re-arrange access to other
(non-volatile) data around
On Friday 2007 August 31, Oleksandr Redchuk wrote:
volatile uint32_t counter;
gcc 4.x produces expected code, but, I think, volatile is not
required in this code.
I'm not sure; I think volatile is exactly what's needed, otherwise gcc is
allowed to assume that the value won't change apart
