[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Const lookup table
From: |
Berni Joss |
Subject: |
Re: [avr-gcc-list] Const lookup table |
Date: |
Sun, 21 Apr 2002 11:11:10 +0200 |
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