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

[Daniel Jacobowitz <drow@mvista.com>]

On Sat, Jan 10, 2004 at 07:58:39PM +0100, Mark Kettenis wrote:
>    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.

Let's see.  gcc/config/i386/i386.c:ix86_return_in_memory:
  if (TARGET_64BIT)
    return !examine_argument (mode, type, 1, &needed_intregs, &needed_sseregs);

So an argument will be passed in memory if examine_argument returns 0.

examine_argument:
  int n = classify_argument (mode, type, class, 0);

  if (!n)
    return 0;
  for (n--; n >= 0; n--)
    switch (class[n])

      case X86_64_X87_CLASS:
      case X86_64_X87UP_CLASS:
        if (!in_return)
          return 0;
        break;

If any of the classes are X87_CLASS or X87UP_CLASS and !in_return,
the argument will be returned in memory.  But in_return is the third
argument, always 1 in this case.  So only if classify_argument returns
0 would a structure be returned in memory.

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.

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer