public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Danny Smith <dannysmith@clear.net.nz>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org, me@cgf.cx
Subject: Re: PATCH [cygwin/mingw ]:  Don't add stdcall suffix to variadic functions
Date: Fri, 16 Jul 2004 08:14:00 -0000	[thread overview]
Message-ID: <001e01c46abb$7ed54070$614861cb@DANNY> (raw)
In-Reply-To: <xyphds98cg3.fsf@miranda.boston.redhat.com>


----- Original Message -----
From: "Jason Merrill"
Subject: Re: PATCH [cygwin/mingw ]: Don't add stdcall suffix to variadic
functions


| On Thu, 15 Jul 2004 18:53:33 +1200 (NZST), Danny Smith  wrote:
|
| > However, for variadic functions, which cannot be handled
| > as __stdcall because the parameter list is indefinite, it
| > leaves off the suffix
| > eg.
| > void __stdcall foo (int a, ...)
| >
| > foo stays as _foo
| >
| > Currently gcc adds @0 suffix to both types of function
| >
| > The following patch makes gcc consistent with native compiler.  It
also
| > rationalizes the two functions gen_fastcall_sufffix  and
gen_stdcall_suffix
| > (which are identical except for two statements) into a single
function
|
| Would it make more sense just to ignore the __stdcall for variadic
| functions, since it doesn't work anyway?

I tried that, by adding a check for TREE_VALUE (tree_last(
TYPE_ARG_TYPES (TREE_TYPE (decl)))
to the attribute handler in i386.c , but it didn't work, because at that
point  TARG_ARG_TYPES is still null.

The __stdcall attribute is ignored  for variadic functions in
ix86_return_pops_args, where a similar check is made.

Danny

Danny
|
| Jason

  reply	other threads:[~2004-07-15 22:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-15 17:08 Danny Smith
2004-07-15 18:16 ` Christopher Faylor
2004-07-15 21:08 ` Jason Merrill
2004-07-16  8:14   ` Danny Smith [this message]
2004-07-17 20:25 Danny Smith

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='001e01c46abb$7ed54070$614861cb@DANNY' \
    --to=dannysmith@clear.net.nz \
    --cc=dannysmith@users.sourceforge.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=me@cgf.cx \
    /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).