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

[Loveny Design]

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?

Jon


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
David Brown
Sent: Friday, 16 May 2008 5:03 PM
To: address@hidden
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

Thomas D. Dean wrote:
> dtostrf also does not impact the value written to PORTA, so, why does
> it not reorder a similar series of statements?
> 

There are several factors that can affect such reordering.  In 
particular, the compiler must know that it is safe to reorder the 
statements.  If the compiler knows that the function is "const" (through 
__attribute__((const)), or if it has the function definition on hand), 
then it can safely be reordered.  "pure" functions (which can also read 
global memory) can be reordered to a lesser extent.

Some maths functions will be declared "const" - others will not, perhaps 
because they set errno, or because they are not re-entrant and use a 
fixed buffer.

Things like compiler versions and optimisation options can obviously 
make a difference.

Sometimes it can be just a matter of luck, as far as the user is 
concerned - small differences in the sizes of functions, the usage of 
local variables, or other minor details can change the result of the 
optimiser output.

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

A liberal sprinkling of "volatile" is the usual way to constrain the 
code in the way you want here.



_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list