On Tue, Apr 28, 2020 at 11:32:02AM -0500, Segher Boessenkool wrote:
> > testcase on powerpc64-linux.  Results:
> 
> You mean powerpc64le-linux here (I hope!)

Yes, sorry.

> > G++ 9 -std=c++14            A, B, C passed in fprs, the rest in gprs
> > G++ 9 -std=c++17            A passed in fprs, the rest in gprs
> > current trunk -std=c++14 & 17       A, B, C passed in fprs, the rest in gprs
> > patched trunk -std=c++14 & 17       A, B, C, F, G, J, K passed in fprs, the 
> > rest in gprs
> > clang++ [*] -std=c++14 & 17 A, B, C, F, G, J, K passed in fprs, the rest in 
> > gprs
> > [*] clang version 11.0.0 (g...@github.com:llvm/llvm-project.git 
> > 5c352e69e76a26e4eda075e20aa6a9bb7686042c)
> > 
> > Is that what we want?  I think it matches the stated intent of P0840R2 or
> > what Jason/Jonathan said, and doing something different like e.g. not
> > treating C, G and K as homogenous because of the int : 0 in empty bases
> > or in zero sized [[no_unique_address] fields would be quite hard to
> > implement (because for C++14 the FIELD_DECL just isn't there).
> 
> I have no idea what "no_unique_address" is (what the name is, mostly?)
> It seems to me that we would be *much* better off saying what we want it
> to *do*, if we are going to depend on that effect anyway!

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0840r2.html
Unlike C, in C++ even fields with empty types are required to have non-zero
sizes (at least one byte), because addresses of different fields can't be
equal.  This attribute says that it can have the same address as other
fields.  The reason why elfv2 homogenous arg passing cares is mainly the
        /* There must be no padding.  */
        if (wi::to_wide (TYPE_SIZE (type))
            != count * GET_MODE_BITSIZE (*modep))
          return -1;
because the type of those fields, which because of the C++ rules must
be non-zero size and only contain padding byte(s), appears to contain this
padding, but because of the attribute DECL_SIZE is actually bitsize_zero
and thus there is no padding.

        Jakub

Reply via email to