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]
Other format: [Raw text]

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


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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #26324|0                           |1
        is obsolete|                            |
  Attachment #26330|0                           |1
        is obsolete|                            |

--- Comment #35 from Iain Sandoe <iains at gcc dot gnu.org> 2012-01-18 13:43:07 UTC ---
Created attachment 26366
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26366
initial fix.


there are a few wrinkles;

1/ the use of epilogue_completed has to be conditional on optimization because
otherwise there's no post-epilogue split pass.

2/ When there's a non-local label in nested code it looks like this:

   bx = got load
   ....
   jmp xxxx

nonlocal:
   do the fixup

xxxx:

which is fine.

However, in except.c we have:
void
expand_dw2_landing_pad_for_region (eh_region region)
{
#ifdef HAVE_exception_receiver
  if (HAVE_exception_receiver)
    emit_insn (gen_exception_receiver ());
  else
#endif
#ifdef HAVE_nonlocal_goto_receiver
  if (HAVE_nonlocal_goto_receiver)
    emit_insn (gen_nonlocal_goto_receiver ());
  else

which causes sequences like this:


   bx = load got  (emits pic base label).

   ... 
   ...

exception_return = > forces in a got restore via the insert of nonlocal goto
rx.

   bx = got restore
   (got correction - uses pic base label)
   ... 

the optimizer figures that the first (got load) is not needed because nothing
touches bx in the meantime -- so it drops the got load.  

Unfortunately, it can't see that the got load is what emits the pic-base label
needed by subsequent pic code (and the correction).  

The nice solution would be to carry the pic-base label in per function visible
RTL and to make all the pic handling "open" in the md ... but that's not going
to happen any time soon (well, not in stage 4 anyways).

So .. the solution I've put in the patch is that we always try to do a pic load
- and we notice (per function) if we've already output the pic-base label.  If
so, we don't try to do it again.

This works (there's a marginal inefficiency in that, once in a while, in
exception handling code you will get a zero correction made), but that's only
on exception non-local jump branches .. so we can probably live with it for
now.

A similar solution works also for PPC (the pic code is a lot more in the md
there - so it's a bit more involved).


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