Jan Waclawek schreef:
Yes, I can agree to that, but I don't know if I could fully characterize =
this as a bug.
Considering this code:
#include <avr/io.h>
#include <stdio.h>
static void test0(void) { char buf[100]; puts(buf);}
static void test1(void) { char buf[110]; puts(buf);}
static void test2(void) { char buf[120]; puts(buf);}
static void test3(void) { char buf[130]; puts(buf);}
static void test4(void) { char buf[140]; puts(buf);}
static void test5(void) { char buf[150]; puts(buf);}
static void test6(void) { char buf[160]; puts(buf);}
static void test7(void) { char buf[170]; puts(buf);}
static void test8(void) { char buf[180]; puts(buf);}
static void test9(void) { char buf[190]; puts(buf);}
int main(void)
{
test0();
test1();
test2();
test3();
test4();
test5();
test6();
test7();
test8();
test9();
}
Running on an atmega48 with only 512 bytes this will "work" (at first
glance). But the optimizer creates this:
push r29
push r28
in r28,__SP_L__
in r29,__SP_H__
subi r28,lo8(-(-1450))
sbci r29,hi8(-(-1450))
in __tmp_reg__,__SREG__
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
Which just is bogus since it is beyond memory.
I would consider this a bug.
Interestingly making all functions use buf[100] the optimizer gets smart
and only uses 100 once:
push r16
push r17
push r29
push r28
in r28,__SP_L__
in r29,__SP_H__
subi r28,lo8(-(-100))
sbci r29,hi8(-(-100))
in __tmp_reg__,__SREG__
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
Here my knowledge of GCC stack optimization stops.
HTH,
Wouter
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list