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

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

[Jason McMullan]

(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.
>From rogers@csbs.utah.edu Wed Jul 26 14:01:00 2000
From: "Alan R. Rogers" <rogers@csbs.utah.edu>
To: gcc-bugs@gcc.gnu.org
Subject: derived class can't invoke base-class constructor
Date: Wed, 26 Jul 2000 14:01:00 -0000
Message-id: <Pine.LNX.4.21.0007261436570.7146-100000@piltdown.anthro.utah.edu>
X-SW-Source: 2000-07/msg00694.html
Content-length: 805

I hope that this bug report will be useful to you.  If the error is in my
source code, then I apologize in advance.

GCC VERSION: 2.95.2

OPERATING SYSTEM: SuSE linux version 6.4 for i386, running Linux
kernel 2.2.9

COMMAND LINE: gcc -c bug.cpp

OUTPUT:

 > gcc -c bug.cpp
bug.cpp: In method `buggy<charT,traits>::buggy(_STL::basic_istream<charT,traits> &)':
bug.cpp:9: Internal compiler error.
bug.cpp:9: Please submit a full bug report.
bug.cpp:9: See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.         

SOURCE:

/** file bug.cpp **/
#include <iosfwd>  // included from STLport-4.0

template <class charT, class traits >
class buggy : std::basic_istream<charT,traits> {
public:
  
  buggy(std::basic_istream<charT,traits>& is)
    : std::basic_istream(  is.rdbuf() )
  {}
};

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

[Jason McMullan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4906 bytes --]

Ovidiu Predescu said with excellent clarity:
> 
> 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!

	I'm just waiting on reports for other architectures.
 
> Just as a curiosity, is the -fdefer-pop optimization performed when the ObjC
> source is compiled with -O?

	Yes. -fdefer-pop is in -O1 and higher.

-- 
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.
>From hjl@lucon.org Thu Jul 27 18:38:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: zack@wolery.cumb.org
Cc: gcc-bugs@gcc.gnu.org
Subject: Does cpp still open many files.
Date: Thu, 27 Jul 2000 18:38:00 -0000
Message-id: <20000727183822.A4501@lucon.org>
X-SW-Source: 2000-07/msg00733.html
Content-length: 210

Hi, Zack,

Have you fixed

http://gcc.gnu.org/ml/gcc/2000-07/msg00037.html

The gcc from CVS has been killing my machine left and right when
I do parallel Linux kernel build on my SMP machines.

Thanks.


H.J.
>From eliz@delorie.com Fri Jul 28 00:40:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gcc-bugs@gcc.gnu.org
Cc: ac131313@cygnus.com
Subject: djunpack.bat
Date: Fri, 28 Jul 2000 00:40:00 -0000
Message-id: <200007280740.DAA19213@indy.delorie.com>
References: <Pine.SUN.3.91.1000727190909.22660E-100000@is> <3980DF63.5F697928@cygnus.com>
X-SW-Source: 2000-07/msg00734.html
Content-length: 521

I noticed in yesterday's CVS tree that the file djunpack.bat is
checked out whenever I say "cvs co gcc".  This file does not belong to
the GCC distribution; it is GDB-specific (it explicitly mentions GDB,
references directories and files that don't exist in the GCC
distribution, etc.).

I have no idea how did it get into the GCC repository.  I don't have
write access to GCC CVS tree, so I couldn't do that even by accident.

I suggest that someone with write access removes this file from the
GCC repository.

Thanks.
>From richard@excel-solutions.co.uk Fri Jul 28 03:00:00 2000
From: "Richard Hann" <richard@excel-solutions.co.uk>
To: <gcc-bugs@gcc.gnu.org>
Subject: GCC/G++ AIX linker problem
Date: Fri, 28 Jul 2000 03:00:00 -0000
Message-id: <003a01bff873$0444abc0$0201a8c0@excelsolutions.co.uk>
X-SW-Source: 2000-07/msg00735.html
Content-length: 1913

GCC Version 2.95.1
IBM AIX  4.1.5
 
Command Line:
    g++ -g -Wall 
--unsigned-char -DUSE_DIRENT -DUNIX -DDISAM -DFFDECL -DUSCHAR 

        
-I/usr/mark/fred/5.30.excel -I/usr/local/include -I/usr/mark/disam/head 
main.cpp
                libbuses_elf.a libtimesheetsui_elf.a libtimesheets_elf.a 
libtimesheetstaticdataui_elf.a         
libtimesheetstaticdata_elf.a libbase_elf.a libevent_elf.a 

        
/usr/mark/fred/5.30.excel/libff_elf.a -lm -o buses 
        
/usr/mark/disam/code/libdisam.a /usr/local/lib/libexpect.a 

        /usr/local/lib/libtcl8.0.a
 

I have a problem with GCC/G++ (GNU C/C++ compiler) 
linking a large
executable under AIX 4.1.5.  The error message 
returned is:
 
ld: 0711-781 ERROR: TOC overflow. TOC size: 
112492   Maximum size 65536
collect2: ld returned 12 exit status
 
The IBM web page documents a similar bug report IX75823 
and an appropriate
fix (PTF) U455193 which I have tried installing to no 
avail. Gnu suggests 
using compiler flags -mminimal-toc which again do not 
seem to have any 
effect.
 
Any ideas or possible work around would be greatly 
appreciated.
 
Richard Hann
 
P.S. All the code compilers, links and runs under 
SCO Openserver 5
 
---------------------------------------------------------------------------- Richard 
Hann                                               
Tel: 01993 200123 Excel Solutions 
Ltd.                                       
Fax: 01993 200220 2 Des Roches Square Witan 
Way Witney Oxfordshire                            
WWW: http://www.excel-solutions.co.uk OX8 
6BE                                
email:  richard@excel-solutions.co.uk ----------------------------------------------------------------------------