Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Kettenis <kettenis@chello.nl>]

   Date: Sat, 10 Jan 2004 13:36:22 -0500
   From: Daniel Jacobowitz <drow@mvista.com>

   On Sat, Jan 10, 2004 at 07:00:35PM +0100, Mark Kettenis wrote:
   > This (together with the previous patch) fixes the problems I saw with
   > gdb.cp/bs15503.exp.  The check for non-POD-ness isn't complete though.
   > I hope to revisit that later, after someone tells me how to properly
   > determine non-POD-ness.
   > 
   > Mark
   > 
   > P.S. The amd64_non_pod_p function should probably be moved to the
   >      generic cod, but we can do that later.

   Does the x86-64 ABI really pass non-POD and POD types of the same size
   differently?  If so, I hope the ABI defines non-POD rather than relying
   on the C++ definition, since we do not generally have enough
   information in the debug info to determine whether a type is POD.

Oh joy, the ABI doesn't define POD-ness.  There's just a footnote
which says:

  The term POD is from the ANSI/ISO C++ Standard, and stands for Plain
  Old Data. Although the exact definition is technical, a POD is
  essentially a structure or union that could have been written in C;
  there cannot be any member functions, or base classes, or similar
  C++ extensions.

And yes, GCC really does pass them differently for aggregates up to 16
bytes in size.

   > +  /* ??? A class with a base class certainly isn't POD, but does this
   > +     catch all non-POD structure types?  */
   > +  if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0)
   > +    return 1;

   No, at least any type with explicitly declared methods is non-POD.  For
   DWARF you can probably get this right by checking for a non-artificial
   method but for stabs you're SOL.

Tried that, and a lot of testcases started FAILing.  Apparently GCC
thinks differently.  In userdef.cc, we have a "class A1" with
explicitly declared methods, but GCC returns instances of "class A1"
in registers nevertheless.

Looks like we can't do very much about it.  Fortunately most real-life
classes will be larger than 16 bytes.

Mark