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

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

Re: [avr-gcc-list] Stack use - possible bug


From: Wouter van Gulik
Subject: Re: [avr-gcc-list] Stack use - possible bug
Date: Wed, 09 Jun 2010 18:16:28 +0200

----- 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


reply via email to

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