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

[Ruud Vlaming]

On Thursday 03 April 2008 01:15, Andy H wrote:

> -fomit-frame-pointer  will work if gcc can really omit it.
> 
> Frame pointer will be used to store "local" variables that are to big 
> to fit in registers and/or need to be saved around calls. It may also
> use R2-R17 to save values. Many factors determine which it will use, 
> such as loops - speed -size - overhead of saving registers etc.  It is 
> not always perfect. 
> 
> If you find situation where it could omit frame pointer - but does not, 
> that might be a bug (gcc is not perfect - I know several parts that 
> could  be better). 

In this case (and many others i have seen) there were plenty of registers 
free to save the variable. I leave it up to you if you call it a bug when i ask
the compiler to omit frame pointers and he still uses one. I think he could
at least warn if he is unable. In the strict sense it is not a bug since the 
documentation states: "Don't keep the frame pointer in a register for 
functions that don't need one"  Given that gcc is not infinitely smart he
might come to the conclusion he needs one. Gcc could also just use push/
pop to temporarily store the variable, but i don't know if that is always 
possible.
 
> By all means post "bug" here first if you are not sure.
That was the intention. Next time i wait a little longer to see more
reactions ;-)

> I know gcc bugs should have pre-processed sources (.i files) - but as first
> look it is easier to just look at c code. I think Eric and others would have
> spotted it sooner. 
I agree 

I would could still use some advise how to resolve the matter. Sometimes 
I need to make a function naked to ensure for example all registers are 
left in tact when jumping to the context switch, cause normally gcc moves 
the registers used for parameters first (prolog) to other registers before
making the call.

So how do i force gcc to use a free register or push/pop directly instead 
of a frame pointer?

> best regards and hope tulips look good.
 /  \   /  \   /  \   /  \  
|    | |    | |    | |    | 
 \  /   \  /   \  /   \  /  
  ||     ||     ||     ||   
  ||     ||     ||     ||   
  ||     ||     ||     ||   

Ruud.

 
> Ruud Vlaming wrote:
> > On Thursday 03 April 2008 00:27, Andy H wrote:
> >   
> >> Not a bug
> >>     
> > Very good spotting. Andy! Thank you!
> >
> > Thats the reason i wanted it to post here before sending in a bug report.
> > Unfortunately i already did so, so i marked the bug as INVALID now.
> > The bugnumber was 35807 
> >
> >   
> >> According to the sources you posted,
> >> privQueuRequestBody
> >> 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 setup.
> >> 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 stack). 
> >>
> >> If you use naked, you must replace all of prolog/epilog by hand. (its 
> >> normal use is for assembler only functions)
> >>     
> >
> > OK, naked is a "dangerous" attribute. I must use it for i do a context save 
> > just before the
> > body function is called, but must preserve all registers so the function 
> > parameters are 
> > left alone. 
> >
> > Is there a way to prohibit the compiler to do so? In other words can i 
> > somehow forbid 
> > to make use of the frame pointer? -fomit-frame-pointer seems not to do the 
> > trick.
> >
> > Since i know on beforehand i will not return from privQueuRequestBody there 
> > is no
> > need to save the stack or so. 
> >
> > Ideas?
> >
> > Ruud.
> >
> >
> > _______________________________________________
> > AVR-GCC-list mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> >   
> 
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>