This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix i386 sibcall-related miscompilations
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: [PATCH] Fix i386 sibcall-related miscompilations
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 7 Jul 2000 10:26:05 +0200
- Cc: gcc-patches at gcc dot gnu dot org, "Jeffrey A. Law" <law at cygnus dot com>
- References: <20000706122734.B5595@sunsite.ms.mff.cuni.cz> <20000706154043.A29493@cygnus.com>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jul 06, 2000 at 03:40:43PM -0700, Richard Henderson wrote:
> On Thu, Jul 06, 2000 at 12:27:34PM +0200, Jakub Jelinek wrote:
> > Can anybody think of a code where virtual_incoming_args_rtx is present
> > outside of MEM expressions and it does not mean taking address of function
> > arguments?
>
> Well, setjmp and non-local goto. But you shouldn't let that stop you.
> I don't see anything else in a quick search.
>
> Err, Jeff, how does PA64's soft argument pointer thing work? Might
> it get in the way here?
Have just checked, PA64 really uses
(insn 4 2 6 (set (reg:DI 66)
(reg:DI 61 virtual-incoming-args)) -1 (nil)
(nil))
Any ideas what we can do then?
As far as I can see, pa's FUNCTION_OK_FOR_SIBCALL is currently 0 for
TARGET_64BIT, so it should not matter right now.
In the PA64 case it could be solved by allowing virtual-incoming-args to be
stored into a register, provided that the register is only used inside of
MEMs in the whole function.
>
> > * sibcall.c (uses_addressof): Add INMEM argument, check for
> > virtual-incoming-args outside of MEM rtxs in addition to ADDRESSOFs.
> > (sequence_uses_addressof): Update caller.
> >
> > * gcc.c-torture/execute/20000706-1.c: New test.
> > * gcc.c-torture/execute/20000706-2.c: New test.
> > * gcc.c-torture/execute/20000706-3.c: New test.
> > * gcc.c-torture/execute/20000706-4.c: New test.
> > * gcc.c-torture/execute/20000706-5.c: New test.
>
> Looks ok. Thanks -- I've known about this one for a while, but hadn't
> gotten around to it.
>
> There is one other outstanding sibcall bug, involving returning a
> struct from a function. The caller adds the structure return address
> as a hidden first argument, and we're not taking that into account
> when deciding how to manipulate the arguments. There was a test case
> posted to gcc-bugs, though I don't remember when now...
It is gcc.c-torture/execute/20000419-1.c, will have a look into it.
There is also another outstanding sibcall ICE which I have under debugger
right now. It shows up when trying to compile sparc64 2.2.16 Linux kernel.
2000-07-07 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/20000707-1.c: New test.
--- gcc/testsuite/gcc.dg/20000707-1.c.jj Fri Jul 7 10:01:36 2000
+++ gcc/testsuite/gcc.dg/20000707-1.c Fri Jul 7 10:02:07 2000
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wall" } */
+
+extern void foo(void *here);
+extern inline void bar(void)
+{
+ __label__ here;
+ foo(&&here);
+here:
+ ;
+}
+
+void baz(void)
+{
+ bar();
+}
Jakub