public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: ekraus02@baker.edu
To: gcc-gnats@gcc.gnu.org
Subject: c/7574: Code generation problem involving regparm attribute
Date: Sun, 11 Aug 2002 18:36:00 -0000	[thread overview]
Message-ID: <20020812004432.11090.qmail@sources.redhat.com> (raw)


>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:


             reply	other threads:[~2002-08-12  0:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-11 18:36 ekraus02 [this message]
2002-12-03 10:02 reichelt
2002-12-10 15:18 reichelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020812004432.11090.qmail@sources.redhat.com \
    --to=ekraus02@baker.edu \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).