target/8839: [gcc 3.1+] i386 code gen problem with fastcall/regparm attr

target/8839: [gcc 3.1+] i386 code gen problem with fastcall/regparm attr

[ekraus02]

>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 *<reg>' 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 <stdio.h>
  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) <garbage>

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:

Re: target/8839: [gcc 3.1+] i386 code gen problem with fastcall/regparm attr

[ehrhardt]

Synopsis: [gcc 3.1+] i386 code gen problem with fastcall/regparm attr

State-Changed-From-To: open->closed
State-Changed-By: cae
State-Changed-When: Fri Dec  6 07:56:51 2002
State-Changed-Why:
    Your code is wrong. The attribute when declaring the Type FooPtr
    applies to the int type not to the function type. Add proper parenthesis
    around your designators like this and it compiles fine:
    
      typedef int (__attribute__ ((regparm (1))) *FooPtr)(int);
    
    regards  Christian

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8839