public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joern Rennecke" <joernr@arc.com>
To: John Fine <johnsfine@verizon.net>
Cc: gcc-help@gcc.gnu.org
Subject: Re: MinGW x86_64 ABI problem
Date: Tue, 24 Feb 2009 14:00:00 -0000	[thread overview]
Message-ID: <20090224140042.GC16609@elsdt-razorfish.arc.com> (raw)
In-Reply-To: <49A3F63C.7020405@verizon.net>

On Tue, Feb 24, 2009 at 08:29:32AM -0500, John Fine wrote:
> There is no instruction to push or pop an xmm register.  The code seems 
> to expect to be able to push and pop.
> 
> If I knew more about gcc internals, I could invent a multi instruction 
> sequence to push or pop, but the result would be very inefficient 
> (because several xmm registers need to be saved and restored in the 
> typical function).

It should be relatively easy to peephole multiple such patterns into
a single one.

> There are architectures that don't have push/pop at all as well as some 
> where push/pop are slower than the alternative.  In many compilers (I 
> assume gcc, but haven't checked) the prolog code can sub the right 
> amount from rsp for both local variables and saving 
> callee-saved-registers, then move those registers into the right place 
> in the stack frame.

Look for ACCUMULATE_OUTGOING_ARGS.

> What/where do I change in gcc to tell it that is the way to save and 
> restore xmm registers.

Gcc either wants to push all register classes or use standard stores
for all.

> Any idea why I don't see this issue discussed on the net, and why 
> someone else hasn't fixed it already?  Or have they and I just haven't 
> looked in the right place?

Either you are looking not hard enough, or noone else has posted about
it yet.

> Doesn't anyone else try to create .lib or .dll files with MinGW that can 
> be called from standard win64 .exe's?

I don't know.  It's been some years since I last looked at MingW.

> As soon as the called function has a few float or double local 
> variables, plus any function up the call stack in the exe also has a few 
> float or double local variables, the result should malfunction.  I can't 
> believe I'm the only one seeing this.

Let's not forget the other preconditions: 64 bit computing,
MingW, and mixing GNU tools with another toolchain.
Each not that uncommon, but the intersection of all these may be small.
And someone has to be the first one to see anything that is to be seen.

  reply	other threads:[~2009-02-24 14:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24 12:45 Joern Rennecke
2009-02-24 13:30 ` John Fine
2009-02-24 14:00   ` Joern Rennecke [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-02-23 15:10 friendly operator overloading Bernd Prager
2009-02-23 16:14 ` Axel Freyn
2009-02-23 22:33   ` MinGW x86_64 ABI problem John Fine
2009-02-24 17:00     ` NightStrike
2009-02-24 17:35       ` John Fine
2009-02-24 18:26         ` NightStrike

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=20090224140042.GC16609@elsdt-razorfish.arc.com \
    --to=joernr@arc.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=johnsfine@verizon.net \
    /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).