----- Oorspronkelijk bericht -----
> Wouter, that's it. I always tried the simplified examples using arrays
> of the same size.
>
> The following:
>
> #include <stdint.h>
> volatile uint8_t b;
>
> int main (void) {
> while(1) {
> {
> uint8_t a1[200];
> b = a1[b];
> }
> {
> uint8_t a2[210];
> b = a2[b];
> }
> }
> }
>
>
> (The read to volatile uint8_t b is to prevent the optimiser to get rid
> of the arrays altogether). As a1[] and a2[] have limited scope/life in
> non-overlapping blocks, they may and should use the same stack space.
> However
>
> 11 main:
> 12 0000 DF93 push r29
> 13 0002 CF93 push r28
> 14 0004 CDB7 in r28,__SP_L__
> 15 0006 DEB7 in r29,__SP_H__
> 16 0008 CA59 subi r28,lo8(-(-410))
> 17 000a D140 sbci r29,hi8(-(-410))
>
> i.e. stack frame of 200 + 210 bytes is used.
>
> The inlined functions are only a variation of this problem.
>
> Still I wouldn't call this a bug, but that's just terminology. Let's
> just call it a serious case of missed optimisation... :-)
>
Well in you're case I would definately call it a missed optimisation. In the
case of inlining and gcc just adding up the stack is IMHO a bug. For -O0 it
works but upgrading to -Os makes the code non functional.
"My" bug might be fixed with using a more sane default for
large-stack-frame-growth as per Davids post.
"Yours" is a more generic bug it seems.
Wouter
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
