Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

[Paulo Marques]

Loveny Design wrote:
> David Brown wrote:
> > The point is, the compiler is allowed to do this sort of optimisation. 
> > It can be a bit annoying during testing and debugging - especially 
> > because such reorderings are relatively rare in practice, so that it's 
> > easy to think "it worked before, what's wrong now?".
>
> I wouldn't have thought the compiler was allowed to re-order statements
> *around* a volatile access. Perhaps someone can help my understanding, given
> :-
> 1: Volatile Statements<sp>
> 2: Statements<sp>
> 3: Volatile Statements<sp>
> where <sp> is a sequence point.
>
> Line 3 has a volatile access and therefore has side-effects that the
> compiler doesn't know about, so surely it must complete all preceeding
> statements up to and including the sequence point before the volatile access
> occurs?

No, because statement 2 doesn't have side effects, so it can not affect 
the outcome of statement 3.

Note! This is not even the worst case for this optimization. The worst 
case I've seen is something like:

int my_flag;

....
cli();
my_flag = 0x1234;
sei();
....

Contrary to what you might expect, that my_flag access isn't being 
protected by the cli/sei pair, and might be reordered by the compiler 
(and "might" here means "it has happened", not some theoretical scenario).

Currently, the official way of doing something like that is using the 
macros provided in <util/atomic.h>.

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"As far as we know, our computer has never had an undetected error."
Weisert