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

[Dale]

Hi

Stumbled onto this due to dire shortage of ram and monitoring stack
usage. To get an idea of whether it was enough, etc.

I'll try and put together sample code which replicates it but the
scenario for now is:

static void initialise(void)
{
charbuf[50];// some data

// call a bunch of functions
}

int main(void) 
{
initialise();

// bunch of stuff
}

Now, initialise() is only ever called once and therefore is optimised
and included inline into main().

What I find is that space used by buf[] is never released from the
stack. There may in fact be more since initialise() calls a whole bunch
of other functions, some of which may or may not have variables on the
stack and/or be one-off functions and as a result 'rolled-into' code
that then forms main().

Given my constrained setup, its critical that this stack space is freed.

Anyone come across this? Is it a known issue?

--

Cheers,

Dale.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Weddington, Eric]

You need to use the noinline function attribute on the initialise() function.

See here:
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html#Function-Attributes
 

Eric

 -Original Message-
 From: 
 avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
 org] On Behalf Of Dale
 Sent: Wednesday, June 09, 2010 6:43 AM
 To: avr-gcc-list@nongnu.org
 Subject: [avr-gcc-list] Stack use - possible bug
 
 Hi
 
 Stumbled onto this due to dire shortage of ram and monitoring stack
 usage. To get an idea of whether it was enough, etc.
 
 I'll try and put together sample code which replicates it but the
 scenario for now is:
 
 static void initialise(void)
 {
   charbuf[50];// some data
 
   // call a bunch of functions
 }
 
 int main(void) 
 {
   initialise();
   
   // bunch of stuff
 }
 
 Now, initialise() is only ever called once and therefore is optimised
 and included inline into main().
 
 What I find is that space used by buf[] is never released from the
 stack. There may in fact be more since initialise() calls a 
 whole bunch
 of other functions, some of which may or may not have variables on the
 stack and/or be one-off functions and as a result 'rolled-into' code
 that then forms main().
 
 Given my constrained setup, its critical that this stack 
 space is freed.
 
 Anyone come across this? Is it a known issue?
 
 --
 
 Cheers,
 
 Dale.
 
 ___
 AVR-GCC-list mailing list
 AVR-GCC-list@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
 

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Dale]

Hi  @2010.06.09_14:42:49_+0200

Here's some code which shows this.

#include stdio.h
#include stdlib.h
#include avr/io.h


static void initialise(void)
{
charbuf[50];
uint8_t i;
// nonsense code that's not optimised away
for (i=0; i50; i++) UDR0 = buf[i];
}

int main(void) 
{
initialise();

// run tasks
while (1) {
// nonsense code that's not optimised away
do { __asm__ __volatile__ (nop); } while (0);
}
}

Built using:

avr-gcc -Os -DF_CPU=14745600UL -mmcu=atmega2561 -c main.c  -o main.o
avr-gcc -mmcu=atmega2561 -DF_CPU-14745600UL main.o 
-Wl,-Map=out.map,--cref,--debug-stubs -o main.elf
avr-objdump -h -S main.elf  main.lss

Assembly output as follows:

0112 main:
 112:   df 93   pushr29
 114:   cf 93   pushr28
 116:   cd b7   in  r28, 0x3d   ; 61
 118:   de b7   in  r29, 0x3e   ; 62
 11a:   e2 97   sbiwr28, 0x32   ; 50
 11c:   0f b6   in  r0, 0x3f; 63
 11e:   f8 94   cli
 120:   de bf   out 0x3e, r29   ; 62
 122:   0f be   out 0x3f, r0; 63
 124:   cd bf   out 0x3d, r28   ; 61
 126:   fe 01   movwr30, r28
 128:   31 96   adiwr30, 0x01   ; 1
 12a:   9e 01   movwr18, r28
 12c:   2d 5c   subir18, 0xCD   ; 205
 12e:   3f 4f   sbcir19, 0xFF   ; 255
 130:   81 91   ld  r24, Z+
 132:   80 93 c6 00 sts 0x00C6, r24
 136:   e2 17   cp  r30, r18
 138:   f3 07   cpc r31, r19
 13a:   d1 f7   brne.-12; 0x130 main+0x1e
 13c:   00 00   nop
 13e:   fe cf   rjmp.-4 ; 0x13c main+0x2a


Space taken on stack: stack pointer on mega2561 are 0x3d and 0x3e.

--

Cheers,

Dale.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Dale]

Hi Eric,   @2010.06.09_15:16:08_+0200

 
 You need to use the noinline function attribute on the initialise() 
 function.
 

Sure, that's one solution. Another is to simply remove static from
initialise(). Its easy if you know which functions are affected.

However, its not always obvious what the compiler is going to do. And
therefore where to do this type of thing. Its the kind of issue that can
catch you unawares.

The optimising is effectively creating stack-space for variables but not
destroying it. The boundary for where the variables are no longer used,
should be known.

 See here:
 http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html#Function-Attributes
  
 
 Eric
 
  -Original Message-
  From: 
  avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
  [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
  org] On Behalf Of Dale
  Sent: Wednesday, June 09, 2010 6:43 AM
  To: avr-gcc-list@nongnu.org
  Subject: [avr-gcc-list] Stack use - possible bug
  
  Hi
  
  Stumbled onto this due to dire shortage of ram and monitoring stack
  usage. To get an idea of whether it was enough, etc.
  
  I'll try and put together sample code which replicates it but the
  scenario for now is:
  
  static void initialise(void)
  {
  charbuf[50];// some data
  
  // call a bunch of functions
  }
  
  int main(void) 
  {
  initialise();
  
  // bunch of stuff
  }
  
  Now, initialise() is only ever called once and therefore is optimised
  and included inline into main().
  
  What I find is that space used by buf[] is never released from the
  stack. There may in fact be more since initialise() calls a 
  whole bunch
  of other functions, some of which may or may not have variables on the
  stack and/or be one-off functions and as a result 'rolled-into' code
  that then forms main().
  
  Given my constrained setup, its critical that this stack 
  space is freed.
  
  Anyone come across this? Is it a known issue?
  
  --
  
  Cheers,
  
  Dale.
  
  ___
  AVR-GCC-list mailing list
  AVR-GCC-list@nongnu.org
  http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
  
 

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Paulo Marques]

Dale wrote:
 Hi  @2010.06.09_14:42:49_+0200
 
 Here's some code which shows this.

This code doesn't show a real bug, because even if the initialize
function weren't inlined, the stack would have to grow when calling it.
If you have enough RAM to support that, you have enough RAM to support
it being left there.

The real bug comes from gcc not reusing that space for other variables
afterwards, or calling other functions that might need that space
without releasing it first.

For instance, if you have another array in main but don't use it until
after you've called initialize, gcc should reuse the same space for the
main array too and not use 100 bytes of stack.

Sometimes this doesn't work correctly, but I wasn't able to produce a
simple case to show this problem (only very complex programs which I
didn't want to post online). :(

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

To know recursion, you must first know recursion.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Dale]

Hi Paulo @2010.06.09_15:29:48_+0200

 Dale wrote:
  Hi  @2010.06.09_14:42:49_+0200
  
  Here's some code which shows this.
 
 This code doesn't show a real bug, because even if the initialize
 function weren't inlined, the stack would have to grow when calling it.
 If you have enough RAM to support that, you have enough RAM to support
 it being left there.
 

True. It shows the concept though.

 The real bug comes from gcc not reusing that space for other variables
 afterwards, or calling other functions that might need that space
 without releasing it first.
 
 For instance, if you have another array in main but don't use it until
 after you've called initialize, gcc should reuse the same space for the
 main array too and not use 100 bytes of stack.
 
 Sometimes this doesn't work correctly, but I wasn't able to produce a
 simple case to show this problem (only very complex programs which I
 didn't want to post online). :(
 

Likewise, which is why I ended up with a crippled sample :-) The concept
is the same.

But you agree that there's stack used and never returned for reuse?

 -- 
 Paulo Marques
 Software Development Department - Grupo PIE, S.A.
 Phone: +351 252 290600, Fax: +351 252 290601
 Web: www.grupopie.com
 
 To know recursion, you must first know recursion.
 

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Colin O'Flynn]

Hi Dale,

 However, its not always obvious what the compiler is going to do. And
 therefore where to do this type of thing.

There are many issues like this that you need to inspect the resulting code
to see what the compiler is doing. In this case it is saving a bit of code
space, but at the expense of more SRAM.

It's fairly typical IMHO to need to rewrite things slightly or just trigger
specific optimizations in the compiler based on how it interprets your code.
The compiler is pretty smart, but they haven't yet got the mind-reading
interface working ;-)

Regards,

  -Colin

-Original Message-
From: avr-gcc-list-bounces+coflynn=newae@nongnu.org
[mailto:avr-gcc-list-bounces+coflynn=newae@nongnu.org] On Behalf Of Dale
Sent: June 9, 2010 2:26 PM
To: Weddington, Eric
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Stack use - possible bug

Hi Eric,   @2010.06.09_15:16:08_+0200

 
 You need to use the noinline function attribute on the initialise()
function.
 

Sure, that's one solution. Another is to simply remove static from
initialise(). Its easy if you know which functions are affected.

However, its not always obvious what the compiler is going to do. And
therefore where to do this type of thing. Its the kind of issue that can
catch you unawares.

The optimising is effectively creating stack-space for variables but not
destroying it. The boundary for where the variables are no longer used,
should be known.

 See here:

http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html#Functi
on-Attributes 
 
 Eric
 
  -Original Message-
  From: 
  avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
  [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
  org] On Behalf Of Dale
  Sent: Wednesday, June 09, 2010 6:43 AM
  To: avr-gcc-list@nongnu.org
  Subject: [avr-gcc-list] Stack use - possible bug
  
  Hi
  
  Stumbled onto this due to dire shortage of ram and monitoring stack
  usage. To get an idea of whether it was enough, etc.
  
  I'll try and put together sample code which replicates it but the
  scenario for now is:
  
  static void initialise(void)
  {
  charbuf[50];// some data
  
  // call a bunch of functions
  }
  
  int main(void) 
  {
  initialise();
  
  // bunch of stuff
  }
  
  Now, initialise() is only ever called once and therefore is optimised
  and included inline into main().
  
  What I find is that space used by buf[] is never released from the
  stack. There may in fact be more since initialise() calls a 
  whole bunch
  of other functions, some of which may or may not have variables on the
  stack and/or be one-off functions and as a result 'rolled-into' code
  that then forms main().
  
  Given my constrained setup, its critical that this stack 
  space is freed.
  
  Anyone come across this? Is it a known issue?
  
  --
  
  Cheers,
  
  Dale.
  
  ___
  AVR-GCC-list mailing list
  AVR-GCC-list@nongnu.org
  http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
  
 

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Jan Waclawek]

The same here, although without inlined functions (or at least I am not aware 
of them).

In a large (generated) main(), stack grew to 600 bytes (which results in 
costly access to local variables, as the Y+d could not reach them), in spite of 
all local variables having strictly confined scope to disjunct blocks.

I could not produce a simple testcase either, that's why I never reported it as 
a bug.

Jan Waclawek



- Original Message ---
Dale wrote:
 Hi  @2010.06.09_14:42:49_+0200
 
 Here's some code which shows this.

This code doesn't show a real bug, because even if the initialize
function weren't inlined, the stack would have to grow when calling it.
If you have enough RAM to support that, you have enough RAM to support
it being left there.

The real bug comes from gcc not reusing that space for other variables
afterwards, or calling other functions that might need that space
without releasing it first.

For instance, if you have another array in main but don't use it until
after you've called initialize, gcc should reuse the same space for the
main array too and not use 100 bytes of stack.

Sometimes this doesn't work correctly, but I wasn't able to produce a
simple case to show this problem (only very complex programs which I
didn't want to post online). :(


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Dale]

Hi Colin @2010.06.09_15:36:23_+0200

 Hi Dale,
 
  However, its not always obvious what the compiler is going to do. And
  therefore where to do this type of thing.
 
 There are many issues like this that you need to inspect the resulting code
 to see what the compiler is doing. In this case it is saving a bit of code
 space, but at the expense of more SRAM.
 
 It's fairly typical IMHO to need to rewrite things slightly or just trigger
 specific optimizations in the compiler based on how it interprets your code.
 The compiler is pretty smart, but they haven't yet got the mind-reading
 interface working ;-)
 

I disagree that its difficult. If the function is called when its not
inline it creates space for local variables on entry and then frees it
up on exit. 

Why, when its inlined, does the compiler 'forget' that... I just think
its being dumb.

 Regards,
 
   -Colin
 
 -Original Message-
 From: avr-gcc-list-bounces+coflynn=newae@nongnu.org
 [mailto:avr-gcc-list-bounces+coflynn=newae@nongnu.org] On Behalf Of Dale
 Sent: June 9, 2010 2:26 PM
 To: Weddington, Eric
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] Stack use - possible bug
 
 Hi Eric,   @2010.06.09_15:16:08_+0200
 
  
  You need to use the noinline function attribute on the initialise()
 function.
  
 
 Sure, that's one solution. Another is to simply remove static from
 initialise(). Its easy if you know which functions are affected.
 
 However, its not always obvious what the compiler is going to do. And
 therefore where to do this type of thing. Its the kind of issue that can
 catch you unawares.
 
 The optimising is effectively creating stack-space for variables but not
 destroying it. The boundary for where the variables are no longer used,
 should be known.
 
  See here:
 
 http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html#Functi
 on-Attributes 
  
  Eric
  
   -Original Message-
   From: 
   avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
   [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
   org] On Behalf Of Dale
   Sent: Wednesday, June 09, 2010 6:43 AM
   To: avr-gcc-list@nongnu.org
   Subject: [avr-gcc-list] Stack use - possible bug
   
   Hi
   
   Stumbled onto this due to dire shortage of ram and monitoring stack
   usage. To get an idea of whether it was enough, etc.
   
   I'll try and put together sample code which replicates it but the
   scenario for now is:
   
   static void initialise(void)
   {
 charbuf[50];// some data
   
 // call a bunch of functions
   }
   
   int main(void) 
   {
 initialise();
 
 // bunch of stuff
   }
   
   Now, initialise() is only ever called once and therefore is optimised
   and included inline into main().
   
   What I find is that space used by buf[] is never released from the
   stack. There may in fact be more since initialise() calls a 
   whole bunch
   of other functions, some of which may or may not have variables on the
   stack and/or be one-off functions and as a result 'rolled-into' code
   that then forms main().
   
   Given my constrained setup, its critical that this stack 
   space is freed.
   
   Anyone come across this? Is it a known issue?
   
   --
   
   Cheers,
   
   Dale.
   
   ___
   AVR-GCC-list mailing list
   AVR-GCC-list@nongnu.org
   http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
   
  
 
 ___
 AVR-GCC-list mailing list
 AVR-GCC-list@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
 

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Weddington, Eric]

 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
 org] On Behalf Of Dale
 Sent: Wednesday, June 09, 2010 7:36 AM
 To: Paulo Marques
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] Stack use - possible bug
 
 But you agree that there's stack used and never returned for reuse?
 

Yes, I can agree to that, but I don't know if I could fully characterize this 
as a bug.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Jan Waclawek]

Yes, I can agree to that, but I don't know if I could fully characterize =
this as a bug.

Call it missed optimisation, then.

JW

- Original Message ---

 But you agree that there's stack used and never returned for reuse?
=20

Yes, I can agree to that, but I don't know if I could fully characterize =
this as a bug.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Paulo Marques]

Dale wrote:
 Hi Paulo @2010.06.09_15:29:48_+0200

Hi, Dale

 Dale wrote:
[...]
 Sometimes this doesn't work correctly, but I wasn't able to produce a
 simple case to show this problem (only very complex programs which I
 didn't want to post online). :(
 
 Likewise, which is why I ended up with a crippled sample :-) The concept
 is the same.
 
 But you agree that there's stack used and never returned for reuse?

Yes, but in the example shown there is no opportunity for reuse, so we
can not know if the compiler would in fact reuse the space or not.

My point is that, in the example, if the compiler actually wrote code to
decrease the stack it would made the code worse, because it would be
doing operations on the stack pointer for nothing.

The problem is that people running gcc on big machines never notice
this. The other crowd that noticed it already was the linux kernel
people were the stack is limited to 4Kb. I'm trying to find a similar
thread that I remember reading on LKML, but my google-fu is letting me
down :(

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

If cats were horses, we could ride up the trees.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Paulo Marques]

Paulo Marques wrote:
 Dale wrote:
 Hi Paulo @2010.06.09_15:29:48_+0200
 
 Hi, Dale
 
 Dale wrote:
 [...]
 Sometimes this doesn't work correctly, but I wasn't able to produce a
 simple case to show this problem (only very complex programs which I
 didn't want to post online). :(
 Likewise, which is why I ended up with a crippled sample :-) The concept
 is the same.

 But you agree that there's stack used and never returned for reuse?
 
 Yes, but in the example shown there is no opportunity for reuse, so we
 can not know if the compiler would in fact reuse the space or not.
 
 My point is that, in the example, if the compiler actually wrote code to
 decrease the stack it would made the code worse, because it would be
 doing operations on the stack pointer for nothing.
 
 The problem is that people running gcc on big machines never notice
 this. The other crowd that noticed it already was the linux kernel
 people were the stack is limited to 4Kb. I'm trying to find a similar
 thread that I remember reading on LKML, but my google-fu is letting me
 down :(

Found it:

http://lkml.org/lkml/2008/8/26/197

It is almost 2 years old, so maybe things are better now.

I actually found this link on an old thread on the avr gcc mailing list
called Stack usage under heavy inlining that I started myself... I
desperately need to go on vacation :P

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

Left to his own devices, he'd be /dev/null.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Colin O'Flynn]

Was it the thread referenced on the previous discussion on this?

That was in 2008:
http://www.mail-archive.com/avr-gcc-list@nongnu.org/msg05295.html

Which references: http://lkml.org/lkml/2008/8/26/197

Regards,

  -Colin

-Original Message-
From: avr-gcc-list-bounces+coflynn=newae@nongnu.org
[mailto:avr-gcc-list-bounces+coflynn=newae@nongnu.org] On Behalf Of
Paulo Marques
Sent: June 9, 2010 3:03 PM
To: Dale
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Stack use - possible bug

Dale wrote:
 Hi Paulo
@2010.06.09_15:29:48_+0200

Hi, Dale

 Dale wrote:
[...]
 Sometimes this doesn't work correctly, but I wasn't able to produce a
 simple case to show this problem (only very complex programs which I
 didn't want to post online). :(
 
 Likewise, which is why I ended up with a crippled sample :-) The concept
 is the same.
 
 But you agree that there's stack used and never returned for reuse?

Yes, but in the example shown there is no opportunity for reuse, so we
can not know if the compiler would in fact reuse the space or not.

My point is that, in the example, if the compiler actually wrote code to
decrease the stack it would made the code worse, because it would be
doing operations on the stack pointer for nothing.

The problem is that people running gcc on big machines never notice
this. The other crowd that noticed it already was the linux kernel
people were the stack is limited to 4Kb. I'm trying to find a similar
thread that I remember reading on LKML, but my google-fu is letting me
down :(

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

If cats were horses, we could ride up the trees.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Wouter van Gulik]

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

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

[Jan Waclawek]

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

  11main:
  12  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... :-)

Jan Waclawek




___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Weddington, Eric]

 

 -Original Message-
 From: Jan Waclawek [mailto:konf...@efton.sk] 
 Sent: Wednesday, June 09, 2010 7:49 AM
 To: Weddington, Eric; Dale; Paulo Marques
 Cc: avr-gcc-list@nongnu.org
 Subject: RE: [avr-gcc-list] Stack use - possible bug
 
 
 Yes, I can agree to that, but I don't know if I could fully 
 characterize =
 this as a bug.
 
 Call it missed optimisation, then.
 

Certainly that's a better description.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Weddington, Eric]

 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
 org] On Behalf Of Paulo Marques
 Sent: Wednesday, June 09, 2010 8:16 AM
 To: Dale
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] Stack use - possible bug
 
 Paulo Marques wrote:
  Dale wrote:
  
  The problem is that people running gcc on big machines 
 never notice
  this. The other crowd that noticed it already was the linux kernel
  people were the stack is limited to 4Kb. I'm trying to find 
 a similar
  thread that I remember reading on LKML, but my google-fu is 
 letting me
  down :(
 
 Found it:
 
 http://lkml.org/lkml/2008/8/26/197
 

I agree with Paulo in that people running on big machines won't notice this or 
even really care.

I have to agree with Linus in that post on this:
Gcc inlining is a total and utter pile of shit. And _that_ is the problem. 
I seriously think we shouldn't allow gcc to inline anything at all unless 
we tell it to. That's how it used to work, and quite frankly, that's how 
it _should_ work.

It's frustrating that GCC attempts to do any implicit inlining based on other 
criteria (marking a function static), or that the inline keyword is 
essentially soft (that it may inline it, but it may not), which then 
necessitates having (nonstandard) function attributes of always_inline and 
noinline. All of this is based on heuristics that is probably not tuned 
correctly for the AVR. Typically if there are any heuristics in GCC for any 
feature, I can almost guarantee that they are not tuned correctly for the AVR. 
Ok, that's probably an overly-pessimistic statement, but hopefully one can 
understand the sentiment.

Unfortunately this is also why I will essentially ignore the issue as stated in 
the original post. It's not a bug, it's probably a missed optimization that 
will probably not get fixed for a long time, and the issue is easily solved by 
being much more explicit to the compiler as to what should be inlined and what 
should not be inlined because the compiler is not psychic and it has no idea 
what the programmer is intending to do with the program. There, I said it. 
There is much bigger fish to fry when it comes to fixing things in the 
compiler. We're talking about applications for a deeply embedded 8-bit system. 
There will always be some level of weirdness, and a much greater burden is 
always placed on the software engineer to be aware of these cases due to 
extreme hardware limitations and the engineering tradeoffs that ensue.

Eric

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

[Jan Waclawek]

 For -O0 it works but upgrading to -Os makes the code non functional.

Indeed. The bug is present only with -O2, -O3 and -Os. -O0 and -O1 produces 
stack frame of expected size...

I'd requalify it from missed optimisation to pessimisation, then... :-)

Jan


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list