Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 20 February 2016 at 23:35, H.J. Lu wrote: > Can a compiler tell if a copy constructor or destructor is trivial > from the class declaration without function body? Yes, the mere presence of the declaration suffices to render it non-trivial (unless explicitly declared "=

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 20 February 2016 at 20:34, H.J. Lu wrote: > Is there a class, which meets the above definition, with a member function > which can't be passed without a memory slot or a register? The EmptyInt class in my first post in this thread. It has no non-static data members, has

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 20 February 2016 at 18:55, H.J. Lu wrote: > struct dummy0 > { > }; > > struct dummy > { > dummy0 d[20]; > > dummy0 * foo (int i); > }; > > dummy0 * > dummy::foo (int i) > { > return [i]; > } > > dummy0 * > bar (dummy d, int i) > { > return d.foo (i); > } 1. This

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 19 February 2016 at 14:35, Michael Matz wrote: > struct S { > S() {something();} > }; > > would be an empty type, and that's not what we want. Why not? The default constructor is never invoked as part of passing such an object around. Its copy constructor is a nop and requires

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 19 February 2016 at 16:27, H.J. Lu wrote: > We want to include static member functions and exclude non-static member > functions. > There's no reason to disallow non-static member functions in general; they have no impact on being trivially copyable or not, only the

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 11 February 2016 at 16:31, H.J. Lu wrote: > struct A { > static void foo (void) (); > static int xxx; > }; What about it? It's an empty struct. (And it declares a function and a variable in the namespace of A, which however do not have any relevant impact here.)

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 22:40, H.J. Lu wrote: > "empty type". An empty type is either an array of empty types or a > class type where every member is of empty type. Note that the term "empty type" is commonly used in type theory to denote a (or the) type with no values. The

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 11 February 2016 at 11:53, H.J. Lu wrote: > Since this isn't Plain Old Data (POD) for the purposes of layout, it > isn't covered by my proposal for psABI. I leave this to C++ ABI. You never define "POD for the purposes of layout", and I can only interpret it as being

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 11 February 2016 at 15:00, H.J. Lu wrote: > I intentionally exclude C++ specific features in my propose. Yet you use a definition from the Itanium C++ ABI which itself depends on multiple definitions in a particular version of the C++ standard, which depend on C++

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 11 February 2016 at 13:58, H.J. Lu wrote: > "POD for the purpose of layout" is defined in the Itanium C++ ABI here: > > http://mentorembedded.github.io/cxx-abi/abi.html#definitions Sorry, I overlooked that. I still stand by my viewpoint however that triviality of copying

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

To avoid depending again on precise wording of definitions in C++ standard it may be worth being explicit about the requirement to be trivially copyable *and* destructible, since although the former implies the latter in the C++ standard this is not obvious from the terminology (although you also