[avr-gcc-list] Re: Strange compile behaviour

[David Brown]

On 02/02/2010 13:57, Han Hoekstra wrote:
> > > What I see no is that when the while loop at the beginning is compiled
> > > into the code, everything is running OK, but when I comment it out, so
> > > it is not in de code, the stack check fails, indicating that __bss_end
> > > and __bss_end + 1 no longer have the specific test values.
> >
> > If you are using interrupts than you might (by accident) be waiting for
> > the moment that no interrupts are being executed. And thus no extra
> > stack usage during your function execution.
> >
> > The code size increment is due to a smart optimization. You force
> > app_TXIncomming to be zero before continuing, gcc notes it and does not
> > do a multiply that saves some pointer calculation and therefore space.
> > So your loop is doing something after all ;)
> >
> > This also indicates app_TXIncomming as not being volatile? Or a gcc
> > optimizer bug.
> >
> > HTH,
> >
> > Wouter
>
> Ok, I did not expect AVR-GCC to be so smart that it would omit the pointer
> calculations, because the while loop would cause app_TXIncomming to be 0,
> that is nice optimizing.

avr-gcc is often surprisingly smart!

> However, what I don't understand is that the while loop does not cause some
> stack overflow, because I have decreased the array to be only a single
> element, so app_TXIncomming is always 0, so the while loop should therefore
> never loop.

Are you absolutely sure that app_TXIncomming is always 0?  Perhaps you 
have a bug in the code that sets it or that calls this code.

mvh.,

David


> It is true that there are a number of interrupts running in the background,
> but they run in both cases, so that should not make a difference.
> Oh and yes, app_TXIncomming is not volatile, making it volatile does not
> change the behavior, the code always sees a stack overflow when the while
> loop is commented out and no stack overflow when the while loop is included.
>
> I will continue to trace my problem, the issue with the difference in
> generated assembly is now clear to me, I can cross that of my list of things
> to look at. Thanks for the explanation.
>
> Greetings,
>     Han