avr-gcc-list
[Top][All Lists]
Advanced

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

[avr-gcc-list] avr-g++ 3.4 optimization issue


From: James Hsu
Subject: [avr-gcc-list] avr-g++ 3.4 optimization issue
Date: Sat, 11 Sep 2004 17:33:33 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Hi all,


I upgraded my compiler version from 3.3 to 3.4 and seem to have found
an interesting issue. After spending a good couple of hours on it, I
think I need to ask around and see if this is reproducible.

Here's the test program:

"t.c"
#include <avr/io.h>
int main(){
 if(PIND & 0x08) PORTD=1;
 if(PIND & 0x80) PORTD=1;
 return 0;
}

The compile command:
avr-gcc -mmcu=atmega8 --save-temps -Wall -Os  t.c
results in t.s with the following snippet in it:
...
       sbis 48-0x20,3
       rjmp .L2
       ldi r24,lo8(1)
       out 50-0x20,r24
.L2:
       sbis 48-0x20,7
       rjmp .L3
       ldi r24,lo8(1)
       out 50-0x20,r24
.L3:
...

Looks perfect.

Now I run the c++ compiler on it...

avr-g++ -mmcu=atmega8 --save-temps -Wall -Os  t.c

...
       in r24,48-0x20
       clr r25
       ldi r18,3
1:      lsr r25
       ror r24
       dec r18
       brne 1b
       andi r24,lo8(1)
       andi r25,hi8(1)
       tst r24
       breq .L2
       ldi r24,lo8(1)
       out 50-0x20,r24
.L2:
       sbis 48-0x20,7
       rjmp .L3
       ldi r24,lo8(1)
       out 50-0x20,r24
.L3:
...

And suddenly it goes half bonkers. I've tried this on a Debian unstable/
avr-gcc_3.4.1 install, and for chuckles I snagged a copy of the
windows build of the same compiler and see the same. I'm *really*
sure that 3.3 didn't do this either.

I usually regard messing with GCC as black-magic, so could someone
offer up suggestions and/or help point this message to the
appropriate people?


James Hsu


reply via email to

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