This is the mail archive of the gcc-patches@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] Fix i386 sibcall-related miscompilations


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

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