[Top][All Lists]

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

Re: [avr-gcc-list] Bad code generated when using volatile keyword/-O0 op

From: Ned Konz
Subject: Re: [avr-gcc-list] Bad code generated when using volatile keyword/-O0 opt?
Date: Sun, 12 Feb 2006 09:20:06 -0800

On Feb 11, 2006, at 10:43 PM, Rick Mann wrote:

Generating code for an ATmega128.

I've boiled this down to a pretty simple case, I think. In the following code, if compiled with -Os, if "d" is made volatile, then it never seems to get past execution in the first delay loop. If it's not volatile, it works correctly. If I compile with -O0, neither volatile nor non-volatile works (same failure mode).

I started experimenting with -O0 (and the volatile keyword) to try to make sure gdb was in sync between source and assembly.

With the volatile keyword, the .lst files shows this for the first loop:

  17:main.c        ****                 d = kD;
100                             .stabn  68,0,17,.LM4-main
101                     .LM4:
102 0016 2983                   std Y+1,r18
103                     .L3:
  18:main.c        ****                 while (d--);
104                             .stabn  68,0,18,.LM5-main
105                     .LM5:
106 0018 8981                   ldd r24,Y+1
107 001a 8150                   subi r24,lo8(-(-1))
108 001c 8983                   std Y+1,r24
109 001e 8981                   ldd r24,Y+1
110 0020 8F3F                   cpi r24,lo8(-1)
111 0022 D1F7                   brne .L3
  19:main.c        ****                 

And without volatile:

  99 0014 8FEF                  ldi r24,lo8(-1)
100                     .L3:
  17:main.c        ****                 d = kD;
  18:main.c        ****                 while (d--);
101                             .stabn  68,0,18,.LM4-main
102                     .LM4:
103 0016 8150                   subi r24,1
104 0018 F0F7                   brcc .L3

Not sure if this is a bug, but it sure seems like it to me. Let me know what other info you might need.

Why does it seem like a bug?

Is this your entire program, or might there be an interrupt handler that's trashing one or another registers or memory locations?

Ned Konz

reply via email to

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