For completeness, and since I got a green flag from its author, I can point you to the specific project where I was hit by this: RCF - Remote Call Framework (http://www.deltavsoft.com/). The problem manifests while receiving packets, and the only way I could make it work when building with clang was to apply the following patch:

Index: src/RCF/ConnectionOrientedClientTransport.cpp

--- src/RCF/ConnectionOrientedClientTransport.cpp (revision 83459)
+++ src/RCF/ConnectionOrientedClientTransport.cpp (working copy)
@@ -353,7 +353,9 @@

         mLastResponseSize += ret;

•        ByteBuffer b(mByteBuffer.release(), 0, ret);
  

•        ByteBuffer const &releasedBuffer = mByteBuffer.release();
  

•        ByteBuffer b(releasedBuffer, 0, ret);    
  

•        mTransportFilters.empty() ?
             onReadCompleted(b) :
             mTransportFilters.back()->onReadCompleted(b);
  

Where ByteBuffer's CCTOR has of course defaults on all the additional arguments

Both GCC and Clang are correct here, even though they differ. Essentially, Clang is applying copy elision more aggressively than GCC, which is causing this code to do something different from what the author expected. Copy elision can be surprising that way, because it's explicitly stated that it can be applied even though it can change the result of programs.

Specifically, what's happening in the first case is that

A other(original.makeA(), PASSED_IN);

is calling a copy constructor (since C++11 [class.copy]p2 considers that constructor a copy constructor). Then, C++11 [class.copy]p31 says that the compiler can omit the call to the copy constructor (3rd bullet):

• when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move

which means that the copy from the temporary "original.makeA()" can be elided, such that "other" directly gets the value of "original.makeA()".

What does makeA() return? Well, we default-construct 'a' (so val has the value DEFAULT_CTOR) and then perform copy elision (the "named return value optimization", or NRVO) to end up directly returning that 'a' (without calling the copy constructor), so the resulting a have val == DEFAULT_CTOR.

The second case is similar. However, makeStaticA() behaves differently because while

static A a;

gets the same val == DEFAULT_CTOR, the return statement cannot perform NRVO when returning a static local variable. Hence, the copy constructor gets called and we get back an object with val == DEFAULT_ARG.

The third and fourth cases don't involve copy elision, since we're coming from an lvalue and not a temporary.

Summing up, Clang is correctly performing copy elision, and the open source library in question will need to be fixed. I strongly suggest eliminating copy constructors that look like

A(A const&, )

and instead splitting them into

A(const A&); // copy constructor
A(const A&, ); // copy + tweak constructor

so that differences in copy elision behavior between compilers don't continue to cause problems.

Reopening this bug as the fact that a copy constructor is being called is irrelevant if the construction is not, in fact, copy construction. p31 is applicable only during copy/move construction. See also CWG535 1 which clarifies that elision can be applied to constructors other than copy and move constructors if they are selected to perform a copy or move operation, and was applied to the working draft at Kona.

Reopening this bug as the fact that a copy constructor is being called is
irrelevant if the construction is not, in fact, copy construction. p31 is
applicable only during copy/move construction. See also CWG535 1 which
clarifies that elision can be applied to constructors other than copy and move
constructors if they are selected to perform a copy or move operation, and was
applied to the working draft at Kona.

Sean makes a good point. Fixed in Clang r152485.