This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux/PPC gcc 2.95.2 - bad access generated when using inline func


> > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> > Date: Wed, 28 Jun 2000 20:57:21 +0200
> > Cc: gcc-bugs@gcc.gnu.org
> > 
> > On Wed, 28 Jun 2000, Geoff Keating wrote:
> > > I get the following code for rtl_soft_cli with -O2 and gcc 2.95.2:
> > >
> > > rtl_soft_cli:
> > >         lis 10,rtl_local@ha
> > >         lwz 0,rtl_local@l(10)
> > >         la 8,rtl_local@l(10)
> > >         andi. 9,0,2
> > >         bc 12,2,.L1240
> > >         lwz 9,-16(1)
> > >         lis 11,last_cli@ha
> > >         lwz 0,4(9)
> > >         stw 0,last_cli@l(11)
> > > .L1240:
> > >         li 0,2
> > >         1:      lwarx   9,0,8
> > >         andc    9,9,0
> > >         stwcx.  9,0,8
> > >         bne     1b
> > >         blr
> > >
> > > I don't see that register 8 has the wrong value.  It looks like it
> > > contains the address of the global variable rtl_local.  Could you be
> > > more specific about what compiler flags you used, what assembler
> > > output you got, and what is wong with it?
> > 
> > Geoff, it seems the problem is using __builtin_return_address in leaf 
> > functions. __builtin_return_address currently returns wrong values if the 
> > current function has no stackframe. See this comment in rs6000.h:
> > 
> > /* Definitions for __builtin_return_address and __builtin_frame_address.
> >    __builtin_return_address (0) should give link register (65), enable
> >    this. */
> > /* This should be uncommented, so that the link register is used, but
> >    currently this would result in unmatched insns and spilling fixed
> >    registers so we'll leave it for another day.  When these problems are
> >    taken care of one additional fetch will be necessary in RETURN_ADDR_RTX.
> >    (mrs) */
> > /* #define RETURN_ADDR_IN_PREVIOUS_FRAME */
> > 
> > I uncommented this, but now I get:
> > 
> > test5.c:10: Internal compiler error:
> > test5.c:10: internal error--unrecognizable insn:
> > 
> > (insn 10 8 0 (set (mem/f:SI (reg:SI 82) 0)
> >         (reg:SI 65 lr)) -1 (insn_list 8 (nil))
> >     (expr_list:REG_DEAD (reg:SI 65 lr)
> >         (expr_list:REG_DEAD (reg:SI 82)
> >             (nil))))
> > 
> > I'm currently playing with rs6000.md, but with my knowledge in there a 
> > solution will take a while... I would appreciate some hints :-).
> 
> Actually, __builtin_return_address (0) should not give the link
> register, because sometimes the link register holds something else,
> like the return address of something called by this function.
> 
> My suspicion is that the right thing to do is force all functions that
> call __builtin_return_address to have a stack frame...  I will think
> about it.

The alpha and ARM ports (and I think one other, though I forget which) 
have exactly the same issue.  Take a look at how they handle this.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]