Re: [avr-gcc-list] Confusing volatile behaviour with 4.6.2

[Andy Warner]

On Mon, Nov 28, 2011 at 6:38 AM, Paulo Marques <address@hidden> wrote:
> [...]
> Does the problem still occur if you assign the variables later and not
> at declaration time, i.e., something like:
>
>        unsigned char status, data;
>        volatile static int slot = SEARCHING;
>
>        status = UCSR0A;
>        data = UDR0;
>
> I don't know from memory if the creation of local variables that are not
> [...]

The problem remains if I split the declaration and assignment of the variables:

ISR(USART0_RX_vect)
{
        uint8_t status, data;
        static int16_t slot = SEARCHING;

        status = UCSR0A;
        data = UDR0;
        if (status & 0x10) {
...

ISR(USART0_RX_vect)
{
 2da:   1f 92           push    r1
 2dc:   0f 92           push    r0
 2de:   0f b6           in      r0, 0x3f        ; 63
 2e0:   0f 92           push    r0
 2e2:   11 24           eor     r1, r1
 2e4:   2f 93           push    r18
 2e6:   3f 93           push    r19
 2e8:   4f 93           push    r20
 2ea:   8f 93           push    r24
 2ec:   9f 93           push    r25
        uint8_t status, data;
        static int16_t slot = SEARCHING;

        status = UCSR0A;
        data = UDR0;
 2ee:   4c b1           in      r20, 0x0c       ; 12
        if (status & 0x10) {
 2f0:   5c 9b           sbis    0x0b, 4 ; 11
 2f2:   18 c0           rjmp    .+48            ; 0x324 <__vector_18+0x4a>
                if (slot == SEARCHING) {
 2f4:   80 91 12 01     lds     r24, 0x0112
 2f8:   90 91 13 01     lds     r25, 0x0113
 2fc:   2f ef           ldi     r18, 0xFF       ; 255
 2fe:   8e 3f           cpi     r24, 0xFE       ; 254
 300:   92 07           cpc     r25, r18
 302:   89 f1           breq    .+98            ; 0x366 <__vector_18+0x8c>
        }
...

What is it about this construct that makes the compiler feel free to reorder ?
I assume this must be a very specific use case I've tripped over, if
volatiles were being reordered wholesale in 4.6.2, I'd expect there to
be many, many problems surfacing.

> And why is the "slot" variable volatile? It seems there is no reason for
> it and it makes the code a lot worse...

You are correct - it was a hangover from some debug while I was
looking into this problem.
-- 
Andy