On Tue, Apr 28, 2020 at 06:45:05PM +0200, Jakub Jelinek wrote: > On Tue, Apr 28, 2020 at 11:32:02AM -0500, Segher Boessenkool wrote: > > > 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?) > > 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.
So the attribute says an object of this struct can have the same address as another object of this struct. But that is not what the backend code uses it for! > > 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! ^^^ I have said it before as well, but it is just getting worse. This kind of frontend code has no business in a backend (all *other* backends might need something similar (or different!), too!) Segher
