[cxx-abi-dev] Volatile nonstatic data members

[Richard Smith]

On 6 March 2015 at 09:35, David Vandevoorde <daveed at edg.com> 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

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);
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.

        Daveed
>
> P.S.: I sent this e-mail from a different account a few days ago.  Sorry
> if anyone sees it twice.
>
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150306/fc1a4fd4/attachment.html>