[Top][All Lists]

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

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

From: David Brown
Subject: [avr-gcc-list] Re: Strange compile behaviour
Date: Tue, 02 Feb 2010 16:07:13 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

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.



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.



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.


reply via email to

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