Don't allow sibcalls on nested functions

Olivier Hainque
Mon Apr 28 10:52:00 GMT 2003

Grr, re-sending a message that bounced after 5 days due a local mail agent
configuration problem. Sorry for the confusion and the induced delay.

----- Forwarded message from Olivier Hainque <> -----

From: Olivier Hainque <>
To: Richard Henderson <>,
	Richard Kenner <>,
Subject: Re: Don't allow sibcalls on nested functions
Date: Wed, 23 Apr 2003 11:32:57 +0200

Richard Henderson wrote:
> On Mon, Apr 21, 2003 at 05:15:48PM -0400, Richard Kenner wrote:
> > +       /* If the called function is nested in the current one, it might
> > +          access some of the caller's arguments, but could clobber them
> > +          beforehand if the argument areas are shared.  */
> Huh?  This doesn't make any sense at all.  When, exactly, 
> are argument areas "shared" between caller and callee?
> "Never" is the condition that comes to mind.

 Catching up email after a couple of days away, so I'll probably need
 to dig a bit before beeing able to provide more detailed info about what
 was exactly happening. Here are a couple of elements, still:

 From direct recollection, the "sharing" issue was related to expand_call:

        /* The argument block when performing a sibling call is the
         incoming argument block.  */
 which turned out to be a problem when a nested sibcalled callee tries to
 access it's caller's incoming argument.

 Below is an excerpt of the *preliminary* analysis performed on the testcase
 when the issue first showed up (was on sparc-solaris). I'm just rebuilding
 with the current sources with the patch removed to see if it reproduces.

 > The -O2 -gnatp asm output for histograms.adb shows the problem:
 > histograms__display:
 >         st      %o0, [%sp+68]     <========== (1)
 >         ld      [%o1], %o0
 >         sethi   %hi(...__wrapper_for_check_zoom_factor.2), %g1
 >         jmpl    %g1 + %lo(...__wrapper_for_check_zoom_factor.2), %g0

 > histograms__display__wrapper_for_check_zoom_factor.2:
 >         save    %sp, -120, %sp
 >         st      %i0, [%fp+68]    <========== (4)
 >         call    histograms__display__check_zoom_factor.0, 0

 > The store (1) retrieves the Zoom_Factor argument and places it on the stack.
 > The store (4) in wrapper_for_... clobbers the value with its input argument.

  Both come from insns like: (set (mem virtual-incoming-args) (reg i0))

  But a sibcall optimization is performed for the call to wrapper_... (see
  that a jmp insn is used), and the two mems end up referencing the same


----- End forwarded message -----

More information about the Gcc-patches mailing list