From: Mark Kettenis <kettenis@chello.nl>
To: drow@mvista.com, jh@suse.cz, aj@suse.de, mark@codesourcery.com
Cc: gdb-patches@sources.redhat.com, gcc@gcc.gnu.org
Subject: Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64
Date: Sun, 11 Jan 2004 12:38:00 -0000 [thread overview]
Message-ID: <200401111237.i0BCbVPL010349@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <20040111041009.GA15714@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 10 Jan 2004 23:10:09 -0500)
[ This might interest GCC folks. The problem we're facing here is
that on AMD64, and other targets that return small structures in
registers, it isn't clear how small C++ classes are returned. Some
are returned in registers and some are returned in memory. The
AMD64 ABI explicitly says that non-POD structures and unions are
returned in memory, but GCC doesn't seem to be ABI-compliant here.
Is this considered to be a bug? ]
Date: Sat, 10 Jan 2004 23:10:09 -0500
From: Daniel Jacobowitz <drow@mvista.com>
Looking at that function it looks like it will even return some classes
with baseclasses in registers. I won't excerpt it here, as it's quite
large. But it iterates over the baseclasses. If none of them are
larger than 16 bytes (a given, if the derived class isn't larger than
16 bytes) or of a variable size (C++ classes are never variably sized I
don't think) or of TFmode/TCmode (128-bit long doubles), I believe that
the aggregate will be returned in registers.
That function just implements the rules for normal C structures. Th
rules are a bit more complex than you say above, but that bit is
implemented correctly in GDB. At least that's the intention. The
decision to not pass certain C++ classes in registers is made
somewhere else, most notably in cp/class.c:finish_struct_bits(), where
TYPE_MODE is set to BLKmode, and TREE_ADDRESSABLE is set. Both
conditions are enough to get the type returned in memory instead of
registers. However, there are more places where TREE_ADDRESSABLE is
tweaked.
The 1996 ANSI C++ draft has the following statement about non-POD-ness:
"A POD-struct is an aggregate class that has no non-static data members
of type pointer to member, non-POD-struct, non-POD- union (or array of
such types) or reference, and has no user-defined copy assignment
operator and no user-defined destructor. Similarly, a POD-union is an
aggregate union that has no non-static data members of type pointer to
member, non-POD-struct, non-POD-union (or array of such types) or
reference, and has no user-defined copy assignment operator and no
user-defined destructor. A POD class is a class that is either a
POD-struct or a POD-union."
So it doesn't say anything about baseclasses. So the code I checked
in is defenitely wrong :-(.
IOW it doesn't look to me as if GCC implements the non-POD rule. You
might wish to try returning a simple non-POD derived class and see what
GCC generates.
Looks very much like it. I can make a class with a user-defined copy
assignment operator that gets returned in registers by GCC. So GCC
doesn't correctly implement the ABI :-(.
The same problem exist on other targets though. I've seen problems on
64-bit SPARC and FreeBSD/i386 too. The FreeBSD/i386 case is
interesting since the other i386 platforms are OK. This is because
FreeBSD uses a different ABI, where -freg-struct-return is the
default. The System V psABI says that all aggregate types are
returned in memory (-fpcc-struct-return). This is probably the reason
why GCC has so many bugs related to returning small structs; the
majority of people hacking on GNU/Linux IA-32 boxen doesn't see the
problems.
Mark
next prev parent reply other threads:[~2004-01-11 12:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-10 18:00 Mark Kettenis
2004-01-10 18:36 ` Daniel Jacobowitz
2004-01-10 18:59 ` Mark Kettenis
2004-01-11 4:10 ` Daniel Jacobowitz
2004-01-11 12:38 ` Mark Kettenis [this message]
2004-01-11 13:29 ` Jan Hubicka
2004-01-12 5:37 ` Mark Mitchell
2004-01-11 15:05 ` Gabriel Dos Reis
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-09 15:39 ` Daniel Jacobowitz
2004-03-19 0:09 ` Mark Mitchell
2004-03-10 3:38 ` Mark Mitchell
2004-03-10 4:21 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
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=200401111237.i0BCbVPL010349@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=aj@suse.de \
--cc=drow@mvista.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jh@suse.cz \
--cc=mark@codesourcery.com \
/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