[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

["iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> 2012-01-14 11:28:11 UTC ---
(In reply to comment #23)
> How would that help?  

well, I wasn't suggesting that it was a complete solution (and I get that we
need to provide the nonlocal_goto_receiver).

My point is that, at the moment, 'foo' from your example below is not saving
the PIC register if it doesn't use it.
so there is no place to restore it from, (and no local label to subtract to
correct its value).

I was figuring the nonlocal_goto_receiver would need to restore in the case
that foo does not use the PIC reg, and correct the value by subtracting a local
offset  if it does. 

With nonlocal goto, you need to recompute the PIC
> register (if different from the function doing nonlocal goto) in the nonlocal
> goto receiver.
> Consider:
> extern void baz (void (*) (void));
> volatile int z, z1;
> static volatile int z2, z3;
> int
> foo (void)
> {
>   __label__ l;
>   void bar ()
>   {
>     goto l;
>   }
>   baz (bar);
>   return z1 + z3;
> l:
>   return z + z2;
> }
> If you attempt to restore the PIC register in bar before doing the jump,
> you'd restore it to baz PIC register rather than foo PIC register.
> md.texi clearly hints it:
> @cindex @code{nonlocal_goto_receiver} instruction pattern
> @item @samp{nonlocal_goto_receiver}
> This pattern, if defined, contains code needed at the target of a
> nonlocal goto after the code already generated by GCC@.  You will not
> normally need to define this pattern.  A typical reason why you might
> need this pattern is if some value, such as a pointer to a global table,
> must be restored when the frame pointer is restored.  Note that a nonlocal
> goto only occurs within a unit-of-translation, so a global table pointer
> that is shared by all functions of a given module need not be restored.
> There are no arguments.
> 
> darwin clearly doesn't have a PIC pointer shared by all functions of a given
> module, therefore it needs to be restored.