-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I believe I've got the de-facto role of clang (linux) maintainer. Clang-linux C++0x support is very shaky (turning it on can break stdlib stuff) unless you have a clang compiled GNU stdlib or libc++. Until Redhat-based and Debian- based distros start shipping Clang with either 0.) clang-compiled GNU stdlib or 1.) clang friendly stdlib, we should probably only try to use C++0x support on Darwin. I need to investigate this more, though. Hopefully there's a way to turn on C++0x support for clang by defining a macro, without making the stdlib believe that clang supports C++0x. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1J0LAACgkQ9cB/V3/s9Ez7VQCghw9PUEXIGEeAVxHC4plk1bUu keAAn3IFI3UeXj1bc3sZc1GIALZJ2dQU =Rboy -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 2 Feb 2011 17:19:41 -0500 Beman Dawes <bdawes@acm.org> wrote:

So it would be nice if we have one or more Clang config maintainers. Marshall works mostly with Darwin, so perhaps you could team with him if Linux is more convenient for you.

This would be ideal. I don't use Darwin, and I never touch clang darwin stuff. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1J2h0ACgkQ9cB/V3/s9Ewy+wCfRK955aneg7jS4+vV80ETeiUg VV4An3S38VSWfgZgyUUqTJojMz/LBPJ9 =Clak -----END PGP SIGNATURE-----

On Wed, Feb 2, 2011 at 1:46 PM, Bryce Lelbach <admin@thefireflyproject.us> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I believe I've got the de-facto role of clang (linux) maintainer. Clang-linux C++0x support is very shaky (turning it on can break stdlib stuff) unless you have a clang compiled GNU stdlib or libc++. Until Redhat-based and Debian- based distros start shipping Clang with either 0.) clang-compiled GNU stdlib or 1.) clang friendly stdlib, we should probably only try to use C++0x support on Darwin. I need to investigate this more, though.

There are a number of inter-related issues here, so let me try to detangle them. Clang itself is just now getting some C++0x support. It has rvalue references, variadic templates, decltype, static_assert, and some other goodies. We think it's in decent shape, but obviously we need more testing coverage. Clang works with a few different C++ standard libraries, and that's where C++0x gets interesting/messy: - libc++ (Clang/LLVM's new C++0x standard library) works great with Clang's C++0x support. - libstdc++ (GCC's C++ standard library) has problems with Clang's C++0x support, for different reasons in different versions: 4.2: "works", because it doesn't use any C++0x features, but of course you don't have any library support libs 4.3, 4.4: fails, because the library was written at a time when rvalue references could bind to lvalues, which they now can't. so, Clang C++0x (correctly) rejects the code. This is just a casualty of shipping compilers and libraries based on an incomplete working paper. 4.5: fails, because the library uses generalized initializer lists, which Clang does not yet implement. 4.6: presumably fails because of both generalized initializer lists and constexpr, neither of which Clang does not yet implement. So, at this point, it only really makes sense to test Clang's C++0x support either with libstdc++'s 4.2's non-C++0x library or with libc++. (I haven't tried Dinkumware or Apache; I suspect they'll need to be taught about Clang first).

Hopefully there's a way to turn on C++0x support for clang by defining a macro, without making the stdlib believe that clang supports C++0x.

I don't think this is going to be practical. For libstdc++, we'll probably have to write off 4.3 and 4.4 as great experiments with C++0x that shouldn't be used for writing actual C++0x code, and we'll have to wait until Clang's C++0x support catches up with GCC used of C++0x in the library for 4.5/4.6. Regarding Beman's original question about <boost/config/compiler/clang.hpp>, I'll be happy to keep it up-to-date with feature checks for Clang, since I'm also the maintainer of the feature checks on the Clang side. I'm not a good candidate for platform champion, though, because I don't watch Boost closely enough to be helpful. - Doug

On 2/5/2011 1:29 PM, Doug Gregor wrote:

On Sat, Feb 5, 2011 at 10:26 AM, Doug Gregor<doug.gregor@gmail.com> wrote:

...

4.6: presumably fails because of both generalized initializer lists and constexpr, neither of which Clang does not yet implement.

English FAIL: Clang implements neither generalized initializer lists nor constexpr. Patches welcome! ;)

"There are a number of inter-related issues here, so let me try to detangle them." English FAIL: There are a number of inter-related issues here, so let me try to untangle them.

On Sat, Feb 5, 2011 at 11:46 AM, Bryce Lelbach <admin@thefireflyproject.us> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat, 5 Feb 2011 10:26:20 -0800 Doug Gregor <doug.gregor@gmail.com> wrote:

...

Clang itself is just now getting some C++0x support. It has rvalue references, variadic templates, decltype, static_assert, and some other goodies. We think it's in decent shape, but obviously we need more testing coverage.

On Darwin. On Linux, clang C++0x support is a moot point because clang-linux uses the GNU stdlib. Also, according to the regression tests, clang + libc++ can't compile most of Boost.

If you're referring to the clang-darwin-libcxx and clang-darwin-libcxx0x testers, a number of failures I looked at were configuration-related, where clang++ wasn't being told to link against libc++. That needs to be sorted out before we can get to the real failures. I suspect it's that clang-darwin et al. need to be taught how to change the standard library.

...

  - libc++ (Clang/LLVM's new C++0x standard library) works great with Clang's C++0x support.

libc++'s build system is very Mac centric. The last time I tried to use it on Linux, I was unsuccessful in doing so, because the build system relied on the existance of a darwin centric build tool. Has this situation changed? Is libc++ supported on Linux?

Yes, it's still a major pain to get libc++ working on Linux. That's a separate issue whose discussion belongs elsewhere.

...

      4.3, 4.4: fails, because the library was written at a time when rvalue references could bind to lvalues, which they now can't. so, Clang C++0x (correctly) rejects the code. This is just a casualty of shipping compilers and libraries based on an incomplete working paper.

4.3 and 4.4 are usable on Linux if C++0x support is disabled. At least, my version of clang is. Mainstream clang was, last time I checked.

Right, 4.3 and 4.4 aren't interesting when looking at C++0x support.

...

      4.5: fails, because the library uses generalized initializer lists, which Clang does not yet implement.

4.5 is semi-usable on Linux - there used to be a boost workaround for the <iomanip> header with 4.5. This was removed.

Okay, it works if you never end up including <iomanip>. That's not a definition of "works" we should advertise :)

...

(I haven't tried Dinkumware or Apache; I suspect they'll need to be taught about Clang first).

Apache's stdlib is not functional.

Okay.

Part of the problem here is that GNU seems to make a policy of changing working parts of their C++(03/99) stdlib to use C++0x features that only G++ supports, without leaving the old, working C++03/C++99 code in place (the <iomanip> header change from 4.4 to 4.5 is an excellent example of this). Given that both Apple and Intel are targets of GNU's political attacks these days, and given that both Clang (an Apple supported compiler) and the intel compiler use the GNU stdlib on Linux, I suspect that GNU is intentionally trying to poison intel-linux and clang-linux.

The more positive view of this situation is that they're nudging these vendors to implement C++0x features, so we can all have a better C++0x standard and start using these features in our day-to-day work. At least, that was my goal when I put C++0x features into libstdc++ :)

However, neither intel or the clang development team seem to be making efforts to move their compilers away from the GNU stdlib on Linux.

Binary compatibility dictates that all of the compilers on the system use the same standard library. Hence, you'll continue to see these compilers supporting the GNU stdlib so long as it is the dominant standard library on the system.

P.S.S. dgregor, don't get me wrong. I really like clang, and I think you guys are doing an excellent job. I have a TON of respect for you. As you probably know, I use clang as my primary compiler, and I invested a substantial amount of time compiling the Linux kernel with clang. I am saddened by the darwin-centric focus that I see in clang. I understand that a good portion of the clang development team is employeed by Apple, and I get that darwin is your focus. But things like the libc++ build system bother me. It would be a simple matter to make libc++ Linux friendly, and that would probably encourage Debian- and Redhat-maintainers of clang packages to ship clang on Linux with libc++ as the default standard library.

We're way out scope for the Boost list, so I'll be super-brief: if it were a "simple matter", someone would have done it by now. - Doug

On Sat, Feb 5, 2011 at 12:41 PM, Christopher Jefferson <chris@bubblescope.net> wrote:

On 5 Feb 2011, at 19:46, Bryce Lelbach (wash) wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat, 5 Feb 2011 10:26:20 -0800 Doug Gregor <doug.gregor@gmail.com> wrote:

...

Clang itself is just now getting some C++0x support. It has rvalue references, variadic templates, decltype, static_assert, and some other goodies. We think it's in decent shape, but obviously we need more testing coverage.

On Darwin. On Linux, clang C++0x support is a moot point because clang-linux uses the GNU stdlib. Also, according to the regression tests, clang + libc++ can't compile most of Boost.

I started those tests just a day ago. I managed to mess up both the user-config.jam, and stopping the results getting submitted to the official boost test page. Hopefully more reasonable tests should appear in the next couple of days.

Great!

Out of interest, how should I best add c++0x to clang? At the moment, I am just passing -std=c++0x as a compileflag.

You might want to use -std=gnu++0x, to enable GNU extensions. That's the same recommendation one usually sees for C++0x in GCC. How is this handled in Boost.Build? Is there some global C++0x feature that we should be hooking into? - Doug

On Sat, Feb 5, 2011 at 3:41 PM, Doug Gregor <doug.gregor@gmail.com> wrote:

On Sat, Feb 5, 2011 at 10:26 AM, Doug Gregor <doug.gregor@gmail.com> wrote:

...

Regarding Beman's original question about <boost/config/compiler/clang.hpp>, I'll be happy to keep it up-to-date with feature checks for Clang, since I'm also the maintainer of the feature checks on the Clang side. I'm not a good candidate for platform champion, though, because I don't watch Boost closely enough to be helpful.

I've updated the Clang configuration in Boost.Config in Boost trunk (r68659) to reflect Clang's C++0x support.

Great!

Please tell me if I'm supposed to merge this to trunk, or whether someone will do so.

Merge to release:-? Yes, please do as soon as clang trunk tests have cycled. Thanks! --Beman