From: Andrew Pinski <pinskia@physics.uc.edu> To: gcc@microbizz.nl Cc: Andrew Pinski <pinskia@physics.uc.edu>, gcc-gnats@gcc.gnu.org, "Gcc-Bugs@Gcc. Gnu. Org" <gcc-bugs@gcc.gnu.org> Subject: Re: other/10901: non-local goto's (still) don't work on apple-powerpc-darwin Date: Wed, 21 May 2003 08:58:21 -0400 This should be target, as it only effects powerpc-apple-darwin. In 3.4 (do not know about 3.3): It looks like the register that is holding the pic address is overwritten in bar so when the jump happens the pic register now holds the pic for bar, not for main so it prints out some garbage. It looks like it should save and restore it in r30 like stack register is. A workaround in 3.4 for applications is to use -mdynamic-no-pic which will get rid of the pic code. Thanks, Andrew Pinski On Wednesday, May 21, 2003, at 06:15 US/Eastern, gcc@microbizz.nl wrote: > extern int puts (const char *); > extern void abort (void); > > int main (void) > { > __label__ l1; > > void foo (void) > { > > void bar (void) > { > puts ("goto l1"); > goto l1; > } > > bar (); > } > > foo (); > abort (); > l1: > puts ("label l1"); > return 0; > } >> How-To-Repeat: > gcc nonlocalgoto.c -o nonlocalgoto -O3 > gcc nonlocalgoto.c -o nonlocalgoto -O0 > >> Fix: > >> Release-Note: >> Audit-Trail: >> Unformatted: > >
extern int puts (const char *); extern void abort (void); int main (void) { __label__ l1; void foo (void) { void bar (void) { puts ("goto l1"); goto l1; } bar (); } foo (); abort (); l1: puts ("label l1"); return 0; } Release: gcc-3.3 Environment: apple-powerpc-darwin How-To-Repeat: gcc nonlocalgoto.c -o nonlocalgoto -O3 gcc nonlocalgoto.c -o nonlocalgoto -O0
One more thing non-local jumps save and restore r2 which is a violatable register under ppc-darwin but not the pic register r31.
confirmed on mainline (20030523).
Hello, I can confirm that this bug also occurs with Apple's gcc 3.1, FSF gcc 3.2.3, 3.3 branch and mainline (20030530). Dara
Keating fixed a similar problem with but __builtin_setjmp so maybe that fix can be copied so that non-local goto restore the PIC register also.
Subject: Re: [ppc-darwin] non-local goto's (still) don't work With the release of gcc 3.4 and gcc 3.3.2 in view, scheduled for October, may I politely draw your attention to the Darwin non-local goto bug PR 10901 ? The Pascal compiler needs the fix. Regards, Adriaan van Os <www.microbizz.nl/gpc.html>
I have tried to figure how to do this maybe someone can give me an hint (I know after the label for the callback (the non-local label), I have to somehow fix the PIC register (r31) but the problem is I do not know what to change in the machine description, I have tried couple of them but they did not work).
I am looking into this. Should look at how S390 implements this: <http://gcc.gnu.org/ml/gcc-patches/2003-09/ msg01872.html>.
Mainline (20031115)
Subject: Re: [ppc-darwin] Darwin back-end May I draw the attention of Darwin back-end maintainers once again to PR10901 ? It is a stated goal of the current gcc development methodology to achieve "higher-quality releases". Regards, Adriaan van Os
Not working on it anymore too much other things to work on.
Subject: Re: [ppc-darwin] non-local goto's (still) don't work Q: What does a Software Project do with Bugs ? A: They Store Them in a Bug Database. Problem Solved ! Q: What does a Software Project do with Bugs That Are Not Welcome ? A: They Store Them in a Bug Database and then Assign Them Low Priority. This is Very Convenient because The Next Release will only target High Priority Bugs. Problem Solved ! Q: What does a Software Project do with Bugs After A Long Period, say 100 years ? A: The Bugs will Be Removed from the Bug Database, as Nobody has Cared About Them Anyway. Problem Solved ! Mr. Cynical
Created attachment 7895 [details] source code for the example let's be more constructive.
Created attachment 7897 [details] test make file illiustrating the problem target "all" makes assembler files, executable files and runs a test. Can you confirm that I got all the command line parameters right?
I should note this also effects i686-darwin also but that should be filed in a different bug.
Our positron branch has the fix for this in it. We should dig it out and submit it.
(In reply to comment #16) > Our positron branch has the fix for this in it. We should dig it out and > submit it. Mike, any news on that? You can still make it in time for the 5th anniversary of this PR! :)
Nope.
Still fails on both ppc-darwin and i386-darwin, for 4.3.2, 4.4.0 and current trunk: $ cat a.c extern int puts (const char *); extern void abort (void); int main () { __label__ l1; void foo () { void bar () { puts ("goto l1"); goto l1; } bar (); } foo (); abort (); l1: puts ("label l1"); return 0; } $ gcc -O3 a.c && ./a.out goto l1 label l1 $ gcc -O0 a.c && ./a.out goto l1 (It also fails with Apple's gcc.)
*** Bug 22119 has been marked as a duplicate of this bug. ***
No problem that it still fails. It will be fixed after the next big-bang, in thirty billion years.
This issue also appears to exist in llvm-gcc-4.2-2.7... llvm-gcc -O3 -fnested-functions pr10901.c pr10901.c: In function 'main': pr10901.c:5: sorry, unimplemented: non-local gotos not supported by LLVM
I have a fix for this in progress see also PR 51784. JFTR, I suspect the issue is moot in clang/llvm because they don't support nested functions AFAICT - but use 'blocks' instead. BTW, is there any access to the 'positron' branch - was it ever on an FSF server?
apple-branch is what's on the FSF server. The positron branch should be on the Apple open source website, though, just grabbing the top of the tree (latest version of gcc-4.2) I think would be preferable. There is a version in the llvm repo, though, it does have all the llvm goop in it as well.
Created attachment 26370 [details] initial fix this shares some changes with the fix to PR51784 (and that is somewhere to read about the issues that prevent an easier fix). AFAICT, the bugs are still present in the Apple OS tree - at least they are with 4.2.1/5577 - which postdates the comments here. Anyway, this is a starting point - I expect that there is scope to tidy it up. As things stand we need to differentiate the load-picbase from the reload-picbase on PPC because more of the work is done in the md. On x86 it's hidden away in i386.c - which made it easier to fix there.
I have done a clean bootstrap of r183305 on powerpc-apple-darwin9 with the patch in comment #25. Regtesting in progress (allow for ~20 more hours), but gcc at -m32 has only 28 failures (including 16 for gcc.dg/simulate-thread/atomic-* instead of usually 12: I cannot say presently if it is due to some slow down due to the patch or because I am using the machine while usually it is only devoted to the test suite).
patch posted. http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02066.html
Author: iains Date: Sun Sep 29 20:14:39 2013 New Revision: 203019 URL: http://gcc.gnu.org/viewcvs?rev=203019&root=gcc&view=rev Log: gcc: PR target/10901 * config/darwin-protos.h (machopic_get_function_picbase): New. * config/darwin.c (machopic_get_function_picbase): New. * config/rs6000/darwin.md (load_macho_picbase_si): Update picbase label for a new func. (load_macho_picbase_di): Likewise. (reload_macho_picbase): New expand. (reload_macho_picbase_si): New insn. (reload_macho_picbase_di): New insn. (nonlocal_goto_receiver): New define and split. * config/rs6000/rs6000.md (unspec enum): Add UNSPEC_RELD_MPIC. (unspecv enum): Add UNSPECV_NLGR. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-protos.h trunk/gcc/config/darwin.c trunk/gcc/config/rs6000/darwin.md trunk/gcc/config/rs6000/rs6000.md
Thanks all.