[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paulo Marques
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Date: Fri, 16 May 2008 13:05:41 +0100
User-agent: Thunderbird (X11/20071210)

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

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;

my_flag = 0x1234;

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."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]