Hi!

On Tue, Apr 28, 2020 at 01:38:52PM +0200, Jakub Jelinek wrote:
> Ok, I've tried:
> struct X { };
> struct Y { int : 0; };
> struct Z { int : 0; Y y; };
> struct U : public X { X q; };
> struct A { float a, b, c, d; };
> struct B : public X { float a, b, c, d; };
> struct C : public Y { float a, b, c, d; };
> struct D : public Z { float a, b, c, d; };
> struct E : public U { float a, b, c, d; };
> struct F { [[no_unique_address]] X x; float a, b, c, d; };
> struct G { [[no_unique_address]] Y y; float a, b, c, d; };
> struct H { [[no_unique_address]] Z z; float a, b, c, d; };
> struct I { [[no_unique_address]] U u; float a, b, c, d; };
> struct J { float a, b; [[no_unique_address]] X x; float c, d; };
> struct K { float a, b; [[no_unique_address]] Y y; float c, d; };
> struct L { float a, b; [[no_unique_address]] Z z; float c, d; };
> struct M { float a, b; [[no_unique_address]] U u; float c, d; };
> #define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s 
> (s); return 0; }
> T (A, a)
> T (B, b)
> T (C, c)
> T (D, d)
> T (E, e)
> T (F, f)
> T (G, g)
> T (H, h)
> T (I, i)
> T (J, j)
> T (K, k)
> T (L, l)
> T (M, m)
> testcase on powerpc64-linux.  Results:

You mean powerpc64le-linux here (I hope!)

> 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!


Segher

Reply via email to