From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Jason McMullan <jmcmullan@linuxcare.com>
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 [thread overview]
Message-ID: <200007272056.NAA20577@orion.nsr.hp.com> (raw)
In-Reply-To: <20000726163607.A13929@port.evillabs.net>
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.
>
next prev parent reply other threads:[~2000-07-27 13:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-26 13:36 Jason McMullan
2000-07-27 13:57 ` Ovidiu Predescu [this message]
2000-07-27 15:44 ` Jason McMullan
2000-07-31 9:41 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200007272056.NAA20577@orion.nsr.hp.com \
--to=ovidiu@cup.hp.com \
--cc=gcc-bugs@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=jmcmullan@linuxcare.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).