Re: Don't allow sibcalls on nested functions

[Olivier Hainque <hainque at act-europe dot fr>]

Some additional input follows, with comments for questions asked by various
persons. Thanks for the provided feedback, btw :)

Olivier Hainque wrote:
> > When, exactly, are argument areas "shared" between caller and callee?
[...]
>  From direct recollection, the "sharing" issue was related to expand_call:
> 
>         /* The argument block when performing a sibling call is the
>          incoming argument block.  */
[...]
>  I'm just rebuilding with the current sources with the patch removed to see
>  if it reproduces.

 The problem is indeed still visible on sparc-solaris, and the same assembly
 output obervations apply.


 Back to previous comments:

 o Richard Kenner mentioned:

  > [...] check whether this can happen in the case of a
  > pointer to the nested function, since that would be harder to fix.

  I don't see why it could not happen, though only on a very limited number
  of targets because indirect sibcalls are rarely supported. They used
  to be inconditionally forbidden, and still are in 3.2 and 3.3, which
  is why the issue did not show up before. I'm still unclear how to deal
  with this.

 o Dale Johannesen wrote:

  > Isn't this what check_sibcall_argument_overlap is supposed to be
  > detecting?

  My understanding is that check_sibcall_argument_overlap looks for
  references inside the _caller_'s code, but the conflicting references
  are in the _callee_'s code here.

 o Zack Weinberg wrote:

  > What about nesting deeper than one level?

  I don't see how this could happen, for visibility reaons. Maybe I just
  misunderstand what you have in mind. Could you please enlighten ?


 Thanks again for all the input. Call expansion is a fairly complex piece of
 code, IMHO, so I may well still be missing something here.

 Olivier