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
next prev parent 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).