From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ovidiu Predescu To: Jason McMullan Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: [PATCH] __builtin_apply / -fdefer-pop bug (ObjC fix!) Date: Thu, 27 Jul 2000 13:57:00 -0000 Message-id: <200007272056.NAA20577@orion.nsr.hp.com> References: <20000726163607.A13929@port.evillabs.net> X-SW-Source: 2000-07/msg00874.html This is really great! People have been complaining about __builtin_* functions for a long time now. There were even thoughts on replacing these functions and use external libraries to solve the method invocation. These solutions however don't solve the forwarding problem so if your fix solves the issue, it would be really nice! Just as a curiosity, is the -fdefer-pop optimization performed when the ObjC source is compiled with -O? Best regards, Ovidiu -- Ovidiu Predescu http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ On Wed, 26 Jul 2000 16:36:07 -0400, Jason McMullan wrote: > (please CC: to me, as I do not follow the *@gcc.gnu.org lists) > > As many well know, GCC since 2.8.x has had a lot > of bugs with the __builtin_apply() function, especially > with the ObjC front-end. Come to find out, it doesn't > appear to be a problem with __builtin_apply() at all, > but with an over-optimization of -fdefer-pop. > > When compiled with -fdefer-pop (without the following > patch) GCC neglects to set the stack pointer appropriately > after the memcpy() call (to move the stack arguments), and > the called function (that __builtin_apply() was trying to call) > is sent a bogus stack pointer. > > With the following patch, a NO_DEFER_POP/OK_DEFER_POP > pair - which temporarily inhibits -fdefer-pop - is placed > around the critical section in: > > gcc/expr.c:expand_builtin_apply() > > Upon recompile of libobjc (or any other source that uses > __builtin_apply()) correct functionality of __builtin_apply > (and henve forward::/performv:: ) is restored to the ObjectiveC > language runtime. > > A closer inspection as to why the -fdefer-pop optimization > fails in this instance should be looked at, but this workaround > appears to mirror similar uses of NO_DEFER_POP/OK_DEFER_POP in > expr.c. > > * gcc/expr.c - Fix expand_builin_apply() due to -fdefer-pop breakage > > ------------------- Cut here ---------------- > --- expr.c.old Wed Jun 30 18:59:55 1999 > +++ expr.c Wed Jul 26 16:21:37 2000 > @@ -9987,6 +9987,8 @@ > rtx old_stack_level = 0; > rtx call_fusage = 0; > > + NO_DEFER_POP; > + > /* Create a block where the return registers can be saved. */ > result = assign_stack_local (BLKmode, apply_result_size (), -1); > > @@ -10145,6 +10147,8 @@ > else > #endif > emit_stack_restore (SAVE_BLOCK, old_stack_level, NULL_RTX); > + > + OK_DEFER_POP; > > /* Return the address of the result block. */ > return copy_addr_to_reg (XEXP (result, 0)); > ------------------- Cut here ---------------- > -- > Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. > 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax > jmcmullan@linuxcare.com, http://www.linuxcare.com/ > Linuxcare. Support for the revolution. >