>
Number: 7574
>
Category: c
>
Synopsis: Code generation problem involving regparm attribute
>
Confidential: no
>
Severity: serious
>
Priority: medium
>
Responsible: unassigned
>
State: open
>
Class: wrong-code
>
Submitter-Id: net
>
Arrival-Date: Sun Aug 11 17:46:01 PDT 2002
>
Closed-Date:
>
Last-Modified:
>
Originator: Eric R. Krause
>
Release: gcc 3.2 20020809 (prerelease)
>
Organization:
>
Environment:
Cygwin 1.3.12, Windows 2000 Professional SP2 (5.0.2195)
AMD Athlon Processor
>
Description:
gcc configuration:
Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/3.2/specs
Configured with: /usr/src/gcc-3.2-20020809/configure --with-gcc --with-gnu-as
--with-gnu-ld --enable-shared --program-suffix=-3.2 --enable-threads=win32
--disable-win32-registry --disable-nls --enable-languages=c,c++
--enable-version-specific-runtime-libs
Thread model: win32
gcc version 3.2 20020809 (prerelease)
Details:
gcc 3.2 produces incorrect code for situations where a function defined with
the regparm (1) attribute is called via a pointer, but only if that pointer is
stored in an array AND the array subscript is used as the pointer.
What I mean by using the array subscript as a pointer, is that the function
would be called with an expression like:
fnPtrArray[x](...);
Note that retrieving the pointer from the array, assigning it to a function
pointer variable, and then dispatching the call using the pointer variable DOES
work as expected with gcc 3.2:
fnPtr = fnPtrArray[x];
fnPtr(...);
Bug:
gcc 3.2 seems not to recognize that the function being called has the regparm
attribute: as a matter of fact, it PUSHES the intended argument value on the
stack, loads the pointer into %eax (where the argument value SHOULD be) and
then does a 'call *%eax'.
gcc 2.95.x would use a different register to set up the call-through-pointer;
%eax contained the correct argument value.
I suspect this problem is also present in gcc 3.1 and gcc 3.1.1.
>
How-To-Repeat:
In the attached tarball, there are two files: x86codebug.c and x86codebug.i.
The latter is the pre-processed output generated under Cygwin.
Compile x86codebug.c _with gcc 3.2_ and run it. The first line of output
should read "Should be 100: 100", but it won't when you run it.
>
Fix:
Workaround: Assign the pointer array element to a temporary, then dispatch the
call using the temporary.
>
Release-Note:
>
Audit-Trail:
>
Unformatted: