This is the mail archive of the gcc@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]

Re: [PATCH] __builtin_apply / -fdefer-pop bug (ObjC fix!)


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 <ovidiu@cup.hp.com>
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 <jmcmullan@linuxcare.com> 
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.
> 


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