Re: [avr-gcc-list] Const lookup table

[Berni Joss]

On Saturday 20 April 2002 08:34 am, Peter Bosscha wrote:
> - In my experience, for really complex programs with loads of local
> variables and complex structures there's even a bug using -O2/-Os. For
> the fundi's: the R28/R29 pointer to the local variables on the stack
> gets clobbered, resulting in your call not returning to the right
> address. The bug is real but I once spent about 4 hours trying to
> recreate it using a simple example. This so I could report the bug,
> unfortunately the bug is pretty elusive and I got fed up.
> In other words: it is not something that people will experience very
> quickly and -Os, -O2 is pretty safe.
>
> In conclusion, it works but there are a number of issues to be aware of
> and undoubtedly you'll hit a wall somewhere. The nice part is that
> there's lots of friendly people around willing to help.
>

The R29 clobbering has been reported to the avr-gcc maintainers, see attached 
email below. I guess the next release of gcc will fix this ...

I fully agree with you that, even in it's present state, the avr-gcc tool 
suite is already very good, and useable for large projects.
As with all C-compilers I've used so far for 8-bit targets, it is highly 
recommended to check the generated machine code to avoid/resolve 
mis-understandings between the programmer and the compiler :-) this is easily 
done by using: avr-objdump -S

Berni.

----------  Forwarded Message  ----------
Subject: Re: GCC peephole2 bug (was Re: your mail)
Date: 12 Feb 2002 22:01:16 +0300
From: Denis Chertykov <address@hidden>
To: Marek Michalkiewicz <address@hidden>
Cc: Berni Joss <address@hidden>, address@hidden


Marek Michalkiewicz <address@hidden> writes:
> > After using avr-gcc for some weeks I've stumbled today over a situation
> > where avr-gcc 3.0.2 seems to generate code corrupting the stack pointer.
> > Sorry if this is a known issue, I failed finding any evidence in the
> > archives.
>
> Congratulations, I can reproduce this bug too.
>
> > The code snippet below shows r29 being used as a temporary register
> > (addr: 27a) shortly before a code section (addr: 288) assuming r28/r29
> > still contains a valid stack pointer value:
>
> Hmm, it seems GCC thinks the frame pointer is only in r28 and r29 is
> unused, usable as a scratch register for define_peephole2?  This is
> wrong of course... (-mrtl dump shows this)
>
> /*****************
> (insn 289 229 59 (parallel[
>             (set (reg:HI 12 r12 [45])
>                 (const_int 1 [0x1]))
>             (clobber (reg:QI 29 r29))
>         ] ) 11 {*reload_inhi} (nil)
>     (expr_list:REG_UNUSED (reg:QI 29 r29)
>         (nil)))
> *****************/
>         ldi r29,lo8(1)
>         mov r12,r29
>         mov r13,__zero_reg__
>
> One such place was in regrename.c, fixed long time ago:
>
> Sat May 19 09:40:45 2001  Denis Chertykov  <address@hidden>
>
>         * regrename.c (regrename_optimize): frame pointer register can
>         use a few hardregs.
>
> Maybe recog.c (peep2_find_free_register) needs a similar change?
>
>       /* And we don't clobber traceback for noreturn functions.  */
>       if ((regno == FRAME_POINTER_REGNUM || regno ==
> HARD_FRAME_POINTER_REGNUM) && (! reload_completed || frame_pointer_needed))
>         continue;
>
> Not sure if there are any other such places in GCC - other targets
> usually have a single frame pointer register so it doesn't matter.
> This is outside the AVR port, so I guess this needs to be discussed
> with more important GCC people...  Denis?

Marek ! You right - IMHO: GCC have a places with wrong interpretation
of frame_pointer_rtx. Just prepare patch and send it to
address@hidden
Usually GCC maintainers quick approves such patches.

Denis.

-------------------------------------------------------
avr-gcc-list at http://avr1.org