> On Mar 6, 2015, at 11:52 AM, Richard Smith <[email protected]> wrote:
> On 6 March 2015 at 09:35, David Vandevoorde <[email protected]
> <mailto:[email protected]>> wrote:
> At some point, the C++ standard changed to cause volatile nonstatic data
> members to make a generated copy/move constructor nontrivial.
>
> To save anyone else looking, this was
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#496
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#496>
>
> Unfortunately, that would change the parameter passing mechanism if we stuck
> to letter of the ABI; see 3.1.1/1:
>
> 1. In the special case where the parameter type has a non-trivial copy
> constructor or destructor, the caller must allocate space
> for a temporary copy, and pass the resulting copy by reference (below).
> Specifically, ...
>
> AFAICT, recent versions of GCC and Clang do implement the language aspects of
> nontriviality of copy/move constructors in such cases (e.g., causing union
> constructors to become deleted), but not this ABI aspect of it.
>
> Clang does not implement this (http://clang.llvm.org/cxx_dr_status.html#496
> <http://clang.llvm.org/cxx_dr_status.html#496>); I'm not sure about GCC
> trunk. We still accept
>
> struct A { volatile int v; };
> union U { A a; };
> extern U u1;
> U u2(u1);
>
> (for example).
>
> For example:
>
> typedef struct { int value; } TypeA;
> typedef struct { TypeA volatile value; } TypeB;
> typedef struct { TypeA value; } TypeC;
>
> int foo(TypeB p) { return p.value.value; }
> int foo(TypeC p) { return p.value.value; }
>
> Identical code is being generated for these two definitions of foo, even
> though TypeB has a nontrivial copy constructor and TypeC has a trivial copy
> constructor.
>
> If that is right, should the 3.1.1/1 words above be edited to read:
>
> 1. In the special case where the parameter type has a non-trivial copy
> constructor (with the exception of a generated copy constructor that is
> nontrivial only because one or more nonstatic data member are trivial) or
> destructor, the caller must allocate space for a temporary copy,
> and pass the resulting copy by reference (below). Specifically, ...
>
> ?
>
> No strong preference here, but...
>
> Do you have any feeling about how much code would be broken if we don't do
> this? If we were starting from a clean sheet, I think I'd prefer the rule as
> it is (volatile subobjects prevent a class from being passed in registers),
> so if this doesn't actually happen in practice, I'd prefer for us to leave
> the ABI alone.
I agree with your abstract preference, but not only is this sheet not clean, it
is actually vellum. This is a C/C++ ABI incompatibility; I don’t remotely see
how we can accept it.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
