[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [avr-gcc-list] avr-g++ 3.4 optimization issue,
James Hsu <=