Fix PR24908: ICE in dwarf2out for cpu2000 with -funroll-loops

Alan Modra amodra@bigpond.net.au
Sat Nov 19 05:50:00 GMT 2005


On Sat, Nov 19, 2005 at 09:57:31AM +1030, Alan Modra wrote:
> On Fri, Nov 18, 2005 at 02:08:41PM -0800, Geoff Keating wrote:
> > I'm pretty sure we can generate them even in the prolog; you see code  
> > like
> > 
> > 	mflr r12  // save return address in r12
> > 	bl __GLOBAL_OFFSET_TABLE__@local
> > 	mflr r28  // save GOT address in r28 (not frame related)
> > 	mtlr r12  // restore return address from r12
> > 
> > I don't know if this code tries to deal with that or not; maybe we  
> > just don't mark the save/restore as frame related and hope that no  
> > trapping operation gets scheduled between the 'mflr' and the 'mtlr'.
> 
> Hmm, if we don't track the restore of lr in this case, then we will
> confuse the unwinder.  Imagine unwinding through a point a little later
> in the function where we have used r12 as a scratch.  Unless we tell the
> unwinder that the return address is no longer in r12, it will use an
> invalid address as the return.

dwarf2out is quite clever and tracks registers with regs_saved_in_regs.
For the testcase in pr24908, I see the following for the code sequence
Geoff shows above, except of course r26 is used instead of r12:

  DW_CFA_register: r108 in r26
  [snip]
  DW_CFA_same_value: r108

The DW_CFA_same_value says lr is restored to its original value.  I
think that regs_saved_in_regs along with the fact that we are only
interested in the prologue means that Geoff's concern about saves vs
restores are covered.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre



More information about the Gcc-patches mailing list