From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15617 invoked by alias); 6 Dec 2002 09:16:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15589 invoked by uid 71); 6 Dec 2002 09:16:00 -0000 Resent-Date: 6 Dec 2002 09:16:00 -0000 Resent-Message-ID: <20021206091600.15588.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, ekraus02@baker.edu Received: (qmail 15502 invoked by uid 61); 6 Dec 2002 09:15:35 -0000 Message-Id: <20021206091535.15501.qmail@sources.redhat.com> Date: Fri, 06 Dec 2002 01:16:00 -0000 From: ekraus02@baker.edu Reply-To: ekraus02@baker.edu To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: target/8839: [gcc 3.1+] i386 code gen problem with fastcall/regparm attr X-SW-Source: 2002-12/txt/msg00344.txt.bz2 List-Id: >Number: 8839 >Category: target >Synopsis: [gcc 3.1+] i386 code gen problem with fastcall/regparm attr >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Fri Dec 06 01:16:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Eric R. Krause >Release: gcc 3.2, gcc 3.2.1 >Organization: >Environment: Cygwin 1.3.17-1, Windows 2000 SP2 Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) >Description: This is not a serious problem, as this construct is not that commonly used. Nonetheless, it is a regression from gcc 2.95.3 and gcc 3.0.4. A function declared with the 'regparm' attribute is not called correctly if the call is made through a function pointer stored in an array, and the array dereference is used as the function pointer expression, as in 'fnptrarray[1](100)'. Assuming 'fnptrarray[1]' contains a pointer to a 'regparm' or 'fastcall' attributed function, the statement fnptrarray[1](100); should pass 100 in either the %eax (regparm) or %ecx (fastcall) register, then load the value of fnptrarray[1] into another register and issue a 'call *' insn. But gcc 3.1+ handles such a call like this: 1. Push 100 onto the stack 2. Load fnptrarray[1]'s value into %eax 3. Execute 'call *%eax' insn It causes miscompilation of a simple program like this: #include int __attribute__ ((regparm (1))) Foo (int x) { return x; } typedef int __attribute__ ((regparm (1))) (*FooPtr)(int); int main(void) { FooPtr ptr_array[2] = { Foo, Foo }; int a = ptr_array[0](100); printf("a = (Should be 100) %d\n", a); return 0; } >How-To-Repeat: Compile the attached program x86fnbug.c with GCC 3.1 or 3.2. The output should be a = (Should be 100) Compilation with gcc 3.0.x or gcc 2.95.x should give the output "a = (Should be 100) 100" >Fix: Don't call a regparm or fastcall function directly through a function pointer stored in an array--store it in a temporary, then call via the temporary pointer variable. >Release-Note: >Audit-Trail: >Unformatted: