can't compile boost::thread with -std=c++0x

[llvmbot]

Bugzilla Link	10945
Resolution	INVALID
Resolved on	Oct 10, 2011 14:15
Version	trunk
OS	Linux
Attachments	Pre-processed source for input "t.cc" (compressed), Error output from compiling with "clang++ -c -std=c++0x t.cc"
Reporter	LLVM Bugzilla Contributor
CC	@dwblaikie,@DougGregor

Extended Description

The following simple source file, "t.cc":

#include <boost/thread.hpp>

Compile successfully using "clang++ -c t.cc", but fails to compile if I use "clang++ -c -std=c++0x t.cc". It compiles successfully with all the versions of g++ I tried (using -std=c++0x), 4.5, 4.6, 4.7-20110914.

I'll add attachments for the pre-processed source file, and the error output files.

boost threads is Debian version 1.46.1-7.

[I guess it's using libstdc++ from gcc 4.6.1, as that's the default system compiler.]

Clang++ version:

clang version 3.0 (http://llvm.org/git/clang.git 9bdbec17c3bc44aaa5ea88c62a958d47d1031016)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Thanks,

-Miles

[DougGregor]

I'm not able to reproduce this failure with top-of-tree Clang (r139901). The attached, preprocessed source compiles without any errors.

Can anyone else reproduce this?

[llvmbot]

I'm not able to reproduce this failure with top-of-tree Clang (r139901). The
attached, preprocessed source compiles without any errors.

Sorry, the pre-processed source I attached was wrong -- I guess I used "-E" without "-std=c++0x" when making it.

I'll upload a correct attachment right away.

[I've verified that the old attachment doesn't produce an error for me either, but the new attachment does.]

Remember to compile with std=c++0x ... :]

Thanks,

-miles

[llvmbot]

Corrected pre-processed source for input "t.cc" (compressed)
The previous pre-processed source file I attached was wrong (I forgot to use -std=c++0x when running the pre-processor).

This is the correct pre-processed source.

[dwblaikie]

From the cfe-dev thread, I think this is by design.

shared_ptr defines a move constructor (t.cc:22083) but relies on a constructor template (immediately above, t.cc:22079) for copy construction. The letter of the law (12.8p7) says:

"If the class definition declares a move constructor or move assignment operator, the implicitly declared copy constructor is defined as deleted; otherwise, it is defined as defaulted"

Without this clause I'm not entirely sure what should've happened - I suppose the default copy ctor should've been implicitly provided (from my cursory glance of the code it seems like the default would've been correct/sufficient) and the constructor template that looks like it could do copy would've been ignored.

With this clause that no longer works, the copy ctor is marked as deleted and fails to compile.

A simpler example is this:

struct foo {
void operator=(foo&&);
} g((foo()));

Which compiles without error in g++ but fails in clang++. So far as I'm reading the spec, clang is correct and GCC is incorrect.

[llvmbot]

Hmm, do other people agree with this interpretation?

I can report a bug with gcc / libstdc++ instead ... :]

[For that purpose, is it ok to quote your analysis, David?]

Thanks,

-Miles

[dwblaikie]

[For that purpose, is it ok to quote your analysis, David?]

Sure, though it probably wouldn't hurt to wait for a second opinion as you mentioned/asked for.
if you want to cc on the gcc/libstdc++/boost (I think the lib bug in this case was in boost's shared ptr, but I didn't actually check, I guess it might've been libstdc++'s) you file, I wouldn't mind seeing how they progress

[DougGregor]

From the cfe-dev thread, I think this is by design.

shared_ptr defines a move constructor (t.cc:22083) but relies on a constructor
template (immediately above, t.cc:22079) for copy construction. The letter of
the law (12.8p7) says:

"If the class definition declares a move constructor or move assignment
operator, the implicitly declared copy constructor is defined as deleted;
otherwise, it is defined as defaulted"

Without this clause I'm not entirely sure what should've happened - I suppose
the default copy ctor should've been implicitly provided (from my cursory
glance of the code it seems like the default would've been correct/sufficient)
and the constructor template that looks like it could do copy would've been
ignored.

With this clause that no longer works, the copy ctor is marked as deleted and
fails to compile.

A simpler example is this:

struct foo {
void operator=(foo&&);
} g((foo()));

Which compiles without error in g++ but fails in clang++. So far as I'm reading
the spec, clang is correct and GCC is incorrect.

Yes, this is correct. GCC 4.6.1 doesn't implement this clause yet, because it came into C++11 relatively late. Closing this as "invalid": it's a GCC and Boost bug, not a Clang bug. There is a little more information here

http://clang.llvm.org/compatibility.html#deleted-special-func