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

[Wim Lewis]

On 11/28/11 5:33 AM, Andy Warner wrote:
> 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.

Me too. Perhaps whatever optimizer rule produces the 'sbis' instruction
doesn't understand that it's reordering volatile operations? Turning on
RTL dumps suggests that the problem shows up after the combine pass.
Maybe someone more familiar with gcc internals could comment.

Running the delta minimizer on the code you posted reduces the test case
to this:

typedef unsigned char uint8_t;
#define SEARCHING (-2)
#define UCSR0A (*(volatile uint8_t *)((0x0B) + 0x20))
#define UDR0 (*(volatile uint8_t *)((0x0C) + 0x20))
void __vector_18(void)
{
        unsigned char status = UCSR0A;
        unsigned char data = UDR0;
        static volatile int slot;
        if (status & 0x10) {
                if (slot == SEARCHING) {
                        slot ++;
                }
        }
}

avr-gcc-4.6.2 -S -mmcu=atmega128 -Wall -fverbose-asm -O2 produces:
[....]
__vector_18:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
        in r24,44-0x20   ;  data, MEM[(volatile uint8_t *)44B]
        sbis 43-0x20,4   ; ,
        rjmp .L1         ;
[....]