[Top][All Lists]

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

Re: [avr-gcc-list] Incorrect code by gcc?

From: Andy H
Subject: Re: [avr-gcc-list] Incorrect code by gcc?
Date: Wed, 02 Apr 2008 18:27:09 -0400
User-agent: Thunderbird (Windows/20080213)

Not a bug

According to the sources you posted,


void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling, uint16_t 
uiTicksToWait) __attribute__ ( ( naked ) );

The relevant part being "naked"

That means gcc will omit prolog - which is where stack and frame pointer are 
R28/29 is the frame pointer. What you see in assembler is gcc saving the 
register around a call. Depending on optimization, it may choose to do this 
rather than use a register (as the register would need to be saved on the 

If you use naked, you must replace all of prolog/epilog by hand. (its normal 
use is for assembler only functions)


Weddington, Eric wrote:
-----Original Message-----
From: address@hidden [mailto:address@hidden
org] On Behalf Of Ruud Vlaming
Sent: Wednesday, April 02, 2008 2:41 PM
To: address@hidden
Subject: [avr-gcc-list] Incorrect code by gcc?


When developing an OS for the smallest Atmels (ATtiny861/461/21)
i observed a strange effect. Sometimes, depending on the optimization
choosen by gcc, the compiler generates code which cannot be correct
(in my  view). Most of the time the code is not functional too.

Hi Ruud,

Thanks for taking the time to write about this.

The best place to submit a bug report for GCC is at the GCC bug
If you send it to a mailing list, it will probably get lost as we get a
lot of emails daily.

When you submit a bug report there do the following:
- For the "Component" field, select "target" (meaning that it is a
problem with the backend)
- For the "Target triplet" field, put in "avr-*-*"
- Write a summary and a description
- Submit the bug report.
- After you submit the bug report, attach your test case (as small as
possible), and any other pertinent files.

It would also be helpful if you can then send an email to this list
(avr-gcc-list) and let us know what the bug number is. I keep track of
all AVR specific bugs in the toolchain at this page here:

Eric Weddington

AVR-GCC-list mailing list

reply via email to

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