[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 --- Comment #50 from Iain Sandoe iains at gcc dot gnu.org --- Author: iains Date: Sun Sep 1 15:39:28 2013 New Revision: 202147 URL: http://gcc.gnu.org/viewcvs?rev=202147root=gccview=rev Log: gcc: Backport from mainline: 2013-07-22 Uros Bizjak ubiz...@gmail.com * config/i386/i386.md (nonlocal_goto_receiver): Delete insn if it is not needed after split. 2013-07-20 Iain Sandoe i...@codesourcery.com PR target/51784 * config/i386/i386.c (output_set_got) [TARGET_MACHO]: Adjust to emit a second label for nonlocal goto receivers. Don't output pic base labels unless we're producing PIC; mark that action unreachable(). (ix86_save_reg): If the function contains a nonlocal label, save the PIC base reg. * config/darwin-protos.h (machopic_should_output_picbase_label): New. * gcc/config/darwin.c (emitted_pic_label_num): New GTY. (update_pic_label_number_if_needed): New. (machopic_output_function_base_name): Adjust for nonlocal receiver case. (machopic_should_output_picbase_label): New. * config/i386/i386.md (enum unspecv): UNSPECV_NLGR: New. (nonlocal_goto_receiver): New insn and split. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/darwin-protos.h branches/gcc-4_7-branch/gcc/config/darwin.c branches/gcc-4_7-branch/gcc/config/i386/i386.c branches/gcc-4_7-branch/gcc/config/i386/i386.md
[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 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reopened as the test gcc.c-torture/execute/pr51447.c still fails on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00136.html ). The test succeeds with the patch for pr10901 at http://gcc.gnu.org/bugzilla/attachment.cgi?id=26370 .
[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 Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #49 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #48) Reopened as the test gcc.c-torture/execute/pr51447.c still fails on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00136.html ). The test succeeds with the patch for pr10901 at http://gcc.gnu.org/bugzilla/attachment.cgi?id=26370 . As Andrew noted above, that was recorded in PR 10901 :) [I have a PPC patch-in-progress - add 10901 to your list, and I'll post to there when ready to test].
[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 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #47 from Dominique d'Humieres dominiq at lps dot ens.fr --- Fixed by revision 201086 Author:iains Date:Sat Jul 20 16:22:59 2013 UTC (6 days ago) Changed paths:5 Log Message: gcc/ PR target/51784 * config/i386/i386.c (output_set_got) [TARGET_MACHO]: Adjust to emit a second label for nonlocal goto receivers. Don't output pic base labels unless we're producing PIC; mark that action unreachable(). (ix86_save_reg): If the function contains a nonlocal label, save the PIC base reg. * config/darwin-protos.h (machopic_should_output_picbase_label): New. * gcc/config/darwin.c (emitted_pic_label_num): New GTY. (update_pic_label_number_if_needed): New. (machopic_output_function_base_name): Adjust for nonlocal receiver case. (machopic_should_output_picbase_label): New. * config/i386/i386.md (enum unspecv): UNSPECV_NLGR: New. (nonlocal_goto_receiver): New insn and split. Thanks for the fix.
[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 --- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 13:45:45 UTC --- (In reply to comment #42) On x86_64-apple-darwin12, while the proposed patch from Comment 42 bootstraps fine, it does produce a new regression at -m64... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ -fno-diagnostics-show-caret -O2 -mcmodel=large -c -m64 -o pr49866.o /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130206/gcc/testsuite/gcc.target/i386/pr49866.c (timeout = 300) /var/tmp//ccgCyUt7.s:11:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:14:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:17:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:48:junk `@PLTOFF' after expression^M compiler exited with status 1 output is: /var/tmp//ccgCyUt7.s:11:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:14:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:17:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:48:junk `@PLTOFF' after expression^M FAIL: gcc.target/i386/pr49866.c (test for excess errors)
[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 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 13:49:36 UTC --- Created attachment 29385 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29385 assembly file for failing gcc.target/i386/pr49866.c compilation at -m64 Compiled with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ -fno-diagnostics-show-caret -O2 -mcmodel=large -c -m64 -o pr49866.o /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130206/gcc/testsuite/gcc.target/i386/pr49866.c --save-temps
[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 --- Comment #45 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-02-07 13:54:07 UTC --- (In reply to comment #43) On x86_64-apple-darwin12, while the proposed patch from Comment 42 bootstraps fine, it does produce a new regression at -m64... This is pr50077 and it has nothing to do with the patch (look at your tests, e.g., http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00522.html). BTW the patch did not cause any new failure on x86_64-apple-darwin10 (as did the previous version).
[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 --- Comment #46 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 16:27:41 UTC --- (In reply to comment #42) Full regression test results on x86_64-apple-darwin12 are at... http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00745.html
[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 #26366|0 |1 is obsolete|| --- Comment #42 from Iain Sandoe iains at gcc dot gnu.org 2013-02-06 09:19:54 UTC --- Created attachment 29363 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29363 updated patch Thanks to my colleague Bernds who identified my mistake (a missing DONE in the splitter). Hopefully this new version addresses Jakub's concerns. folks, please test it across the x86 Darwin versions you have (I've bootstrapped all langs, incl Ada, on x86 Darwin9 where it appears to DTRT). Will update my tree and do a full regtest now.
[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 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #41 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-15 18:15:24 UTC --- *** Bug 52444 has been marked as a duplicate of this bug. ***
[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 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.1 |---
[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 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.0 |4.7.1 --- Comment #40 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-22 08:27:08 UTC --- GCC 4.7.0 is being released, adjusting target milestone.
[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 --- Comment #37 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-19 11:03:58 UTC --- Regstrapped with the patch in comment #35. The patch fixes this PR without regression (down to 2 failures with some pending patches) and the tests for pr10901 pass with the different options I have tried. Thanks.
[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 --- Comment #38 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 11:30:37 UTC --- If the insn pattern is #, then if no split pass splits it before final, during final it will be split anyway. So no idea why you play games with !optimize vs. optimize.
[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 --- Comment #39 from Iain Sandoe iains at gcc dot gnu.org 2012-01-19 12:01:32 UTC --- (In reply to comment #38) If the insn pattern is #, then if no split pass splits it before final, during final it will be split anyway. So no idea why you play games with !optimize vs. optimize. hm. well, without that I was hitting the 'unreachable' here ... final.c:2715 if (new_rtx == insn PATTERN (new_rtx) == body) fatal_insn (could not split insn, insn); #ifdef HAVE_ATTR_length /* This instruction should have been split in shorten_branches, to ensure that we would have valid length info for the splitees. */ gcc_unreachable (); #endif
[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
nonlocal:
do the fixup
:
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).
[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 --- Comment #36 from Iain Sandoe iains at gcc dot gnu.org 2012-01-18 13:47:36 UTC --- (In reply to comment #34) 5) to determine if you need to load the pic register or not, you should match what the prologue expansion does, try (pic_offset_table_rtx (df_regs_ever_live_p (REAL_PIC_OFFSET_TABLE_REGNUM) || crtl-profile)) nothing seems to use df_regs_ever_live_p in the md files, and the function is not visible. I also wonder if it is updated during RTL optimization? (I tried making a function in i386.c that performed these tests and was visible from the md - but it didn't work). For now, I've used crtl-uses_pic_offset_table which seems to work. Is there any other suggestion? probably also anded with !current_function_is_leaf - non-local goto receiver in leaf functions doesn't make much sense and certainly doesn't need to restore PIC pointer, plus it will simplify it (for leaf functions we sometimes decide to use a different register as pic pointer instead of %ebx). hopefully using pic_offset_table_rtx will pick up the current one?
[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 --- Comment #32 from Iain Sandoe iains at gcc dot gnu.org 2012-01-15 11:16:42 UTC --- Created attachment 26329 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26329 test code firstly, apropos comment #22 and #23. If you build this test case under linux (or darwin), -fpic -O0 .. you will see that the prologue of x does not save ebx. However it is used in y ... and to quote function.h the exit block is reachable directly from a nonlocal label. So I think my comment #22 stands. [if you build the testcase -O0 -fpic -DUSEPIC, then x uses the pic reg and all is OK]. this could be fixed thus (but you might well have a better place/way to fix it): Index: gcc/config/i386/i386.c === --- gcc/config/i386/i386.c(revision 183180) +++ gcc/config/i386/i386.c(working copy) @@ -8698,7 +8698,8 @@ ix86_save_reg (unsigned int regno, bool maybe_eh_r (df_regs_ever_live_p (REAL_PIC_OFFSET_TABLE_REGNUM) || crtl-profile || crtl-calls_eh_return - || crtl-uses_const_pool)) + || crtl-uses_const_pool + || cfun-has_nonlocal_label)) return ix86_select_alt_pic_regnum () == INVALID_REGNUM; if (crtl-calls_eh_return maybe_eh_return)
[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 --- Comment #33 from Iain Sandoe iains at gcc dot gnu.org 2012-01-15 11:25:31 UTC --- Created attachment 26330 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26330 second (non working) go I'm finding this moderately hard. I understand what you're suggesting that I should do - but between gccint.pdf, looking at other .md files and so on there is really rather scarce information -- trial error is not a productive way forward .. so I'm still a bit stuck. The attached does the right thing with the testcase - it inserts the restore when PIC is used and not when it isn't. But the compiler fails to bootstrap because eh_personality.cc in the c++ library seems to cause the insert of the nonlocal_rx (for eh) but then, somehow the initial use of the pic register is optimized away .. and thus we end up with a load of L03$pd can't be undefined... ... so ... how can I ensure that the test of uses_pic_ is only done after optimization? (or any other help would be welcome).
[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 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-15 12:05:20 UTC --- (In reply to comment #33) 1) the define_expand isn't needed, just name the define_insn_and_split pattern as nonlocal_goto_receiver. 2) it should split always, either to nothing if nothing is needed, or to the set_got_* plus adjust, so use # as the pattern 3) length attribute doesn't make sense for always split insn 4) the split condition should be epilogue_completed 5) to determine if you need to load the pic register or not, you should match what the prologue expansion does, try (pic_offset_table_rtx (df_regs_ever_live_p (REAL_PIC_OFFSET_TABLE_REGNUM) || crtl-profile)) probably also anded with !current_function_is_leaf - non-local goto receiver in leaf functions doesn't make much sense and certainly doesn't need to restore PIC pointer, plus it will simplify it (for leaf functions we sometimes decide to use a different register as pic pointer instead of %ebx).
[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 --- Comment #22 from Iain Sandoe iains at gcc dot gnu.org 2012-01-14 10:34:19 UTC --- I suppose that, for a start, if a function contains a non-local-label, then the pro/epilogue should save/restore all call-saved regs?
[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
--- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-14
11:03:26 UTC ---
How would that help? 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.
[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
--- 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.
[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 --- Comment #25 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-14 11:33:20 UTC --- I don't think this is a regression - I think it's been there for(ever/long time). I don't want to waste time arguing about the regression tag, but gcc.dg/tree-prof/pr44777.c and its avatars gcc.c-torture/execute/comp-goto-2.c and gcc.c-torture/execute/920501-7.c pass (I do not say work) with -fprofile-generate -D_PROFILE_GENERATE -m32 for gcc 4.6.2 or for trunk with r182920 reverted on x86_64-apple-darwin10 (i.e. no pr44777 on this platform). I guess xfailing is the thing to do for now ... I hate xfail in this kind of situation: I see it as a hypocritical way to say won't fix. Note the test passes with -fno-pic, so I'ld prefer an additional option -fno-pic for darwin. BTW what happens on i?86-linux-* with -fpic?
[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 --- Comment #26 from Iain Sandoe iains at gcc dot gnu.org 2012-01-14 11:42:41 UTC --- (In reply to comment #25) I guess xfailing is the thing to do for now ... I hate xfail in this kind of situation: I see it as a hypocritical way to say won't fix. Note the test passes with -fno-pic, so I'ld prefer an additional option -fno-pic for darwin. well, I tend to agree about xfails hiding problems away - not a fan either. However, this problem is not directly related to the test-case (it just happens to reveal it). I think we will try to fix this bug - it seems quite serious ... so we could also decide to live with the test-suite noise? BTW what happens on i?86-linux-* with -fpic? I think as Jakub mentioned, the _GOT solution will not exhibit this problem.
[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 --- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-14 11:48:37 UTC --- (In reply to comment #25) BTW what happens on i?86-linux-* with -fpic? You haven't read #c17, right? But if you want even further details: Both x and y there have: call__x86.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx i.e. %ebx after these two insns doesn't contain some address within the function, but address of the _GLOBAL_OFFSET_TABLE_ symbol in the current shared library or binary. So, there is no need to restore anything, as nonlocal goto can only be from a nested function to a function within the same translation unit and thus shared library or binary, thus they have the same %ebx value.
[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 --- Comment #28 from Iain Sandoe iains at gcc dot gnu.org 2012-01-14 15:58:32 UTC --- Created attachment 26324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26324 a first attempt at a fix this is pretty much the first ever RTL I've written ... so comments welcome ... I've had a quick look at the output on a couple of test-cases and it seems to DTRT .. but it's hardly tested so far.
[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 --- Comment #29 from Iain Sandoe iains at gcc dot gnu.org 2012-01-14 16:37:38 UTC --- never mind, it doesn't bootstrap...
[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 --- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-14 16:56:10 UTC --- (In reply to comment #28) Created attachment 26324 [details] a first attempt at a fix this is pretty much the first ever RTL I've written ... so comments welcome ... I've had a quick look at the output on a couple of test-cases and it seems to DTRT .. but it's hardly tested so far. That #if TARGET_MACHO and if (TARGET_MACHO) is unneeded, the condition already guards it. If it was using some darwin specific functions or macros, you'd just surround the body in #if TARGET_MACHO. Furthermore, you don't know during expansion whether the PIC pointer will be emitted or not, therefore probably the nonlocal goto receiver (with the condition you've used) should be initially an instruction with unspec_volatile UNSPECV_NONLOCAL_GOTO_RECEIVER or so, and only split after prologue is emitted, either into nothing (if the PIC register doesn't need to be restored), or to the actual instructions.
[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 --- Comment #31 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-14 19:01:47 UTC --- (In reply to comment #20) Doesn't powerpc-darwin have the same problem? Yes that was recorded in PR 10901 :)
