Using C++11 in clang/tools/extra

Hi all,

It came up in a recent code review (http://llvm-reviews.chandlerc.com/D136) that C++11 features aren't allowed in the codebase. I can understand the reason for this in the LLVM and clang codebases as they're both widely used. However, would it be a problem to use C++11 officially in clang/tools/extra? It's not nearly as widely used and has less of a chance of impacting critical work in the community. Are there other problems I'm missing? If not, could the use of C++11 in clang/tools/extra be officially blessed?

Hi all,

It came up in a recent code review (http://llvm-reviews.chandlerc.com/D136) that C++11 features aren't allowed in the codebase. I can understand the reason for this in the LLVM and clang codebases as they're both widely used. However, would it be a problem to use C++11 officially in clang/tools/extra? It's not nearly as widely used and has less of a chance of impacting critical work in the community. Are there other problems I'm missing? If not, could the use of C++11 in clang/tools/extra be officially blessed?

I'd +1 this but with a few points:

1) one of the reasons C++11 isn't allowed is a bootstrapping issue (if
we use the full power of C++11 that only Clang implements, how do we
compile Clang? Do we end up in a situation where you have to build a
series of older Clang's to step up to the latest?). This argument only
really applies to the core path through the compiler - enough that we
can build a Clang that can compile C++11. (this could, for example,
mean that many of the middle end optimizers in LLVM could be written
in C++11, so long as enough were kept in C++98 that we could
bootstrap)

2) Clang selfhosting isn't a bulletproof option on every platform.
Windows support, for example, is still a bit patchy. So we might need
to restrict ourselves to the subset of C++11 available on a reasonable
selection of platforms/compilers.

This is already being done in the lld project so we do have precedent
for one possible set of tradeoffs & choices in this regard.

- David

Since clang/tools/extra is not necessary to build/run clang itself I think this repo is safe from these points.

One of the problems with doing this (as we've found with lld), is that you need to link it against a set of clang libraries that are also built with C++11.

-- Marshall

Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

Really? What happens if you link against libraries not built with C++11? Do you get undefined behaviour? We've been building and running our tools in clang/tools/extra with C++11 turned on and have had no trouble linking with clang libraries so far.

Really? What happens if you link against libraries not built with C++11? Do you get undefined behaviour? We've been building and running our tools in clang/tools/extra with C++11 turned on and have had no trouble linking with clang libraries so far.

Are you turning on C++11 just for the tools? not for the LLVM/Clang
build overall?

Obvious breakage would be: Any STL type used across the boundary
(though we don't have many standard container types in LLVM/Clang
compared to custom data structures like DenseMap, etc) could be quite
broken.

Less obvious: ODR violations in both standard types and non-standard
types (several of the core LLVM data structures have move semantics
explicitly defined conditional on being compiled with C++11 - that
means LLVM (if you compile it as C++98) would see one definition of
this type and your tool would see a different definition. This is an
ODR violation & All Bets Are Off)

- David

I've had no problem building lld with C++11 and llvm with C++03. The one change I did need to make to the llvm build was to build with -stdlib=libc++. That is, use the new libc++ standard library for both projects.

-Nick

I suspect that what Marshall has hit is that libstdc++ has
ABI-breaking changes when compiled in C++11 mode vs. C++03 mode. I
don't know if anyone has audited libc++ for such changes, it took us
some time to find them in libstdc++, but they led to moderately
terrible bugs.

-Chandler

IIRC, Howard tried to be pretty careful about making C++03 and C++11
in libc++ binary-compatible (unlike libstdc++, which had intentional
differences). Of course, it's possible there are bugs.

-Eli

That would be quite impressive, and very useful.

Anyways, there are folks that need to use llvm, lld, and
clang-tools-extra with libstdc++, and for them it is important to
build llvm in C++11 mode. Honestly, we should be building llvm in
C++11 mode whenever it is possible because of the performance
benefits, so I don't see this as a barrier anyways....

It came up in a recent code review (http://llvm-reviews.chandlerc.com/D136) that C++11 features aren't allowed in the codebase. I can understand the reason for this in the LLVM and clang codebases as they're both widely used. However, would it be a problem to use C++11 officially in clang/tools/extra? It's not nearly as widely used and has less of a chance of impacting critical work in the community. Are there other problems I'm missing? If not, could the use of C++11 in clang/tools/extra be officially blessed?

One of the problems with doing this (as we've found with lld), is that you need to link it against a set of clang libraries that are also built with C++11.

I've had no problem building lld with C++11 and llvm with C++03. The one change I did need to make to the llvm build was to build with -stdlib=libc++. That is, use the new libc++ standard library for both projects.

I suspect that what Marshall has hit is that libstdc++ has
ABI-breaking changes when compiled in C++11 mode vs. C++03 mode. I
don't know if anyone has audited libc++ for such changes, it took us
some time to find them in libstdc++, but they led to moderately
terrible bugs.

IIRC, Howard tried to be pretty careful about making C++03 and C++11
in libc++ binary-compatible (unlike libstdc++, which had intentional
differences). Of course, it's possible there are bugs.

libc++ is ABI compatible with itself across C++03 and C++11. Low-level parts of libc++ (typically implemented in libc++abi today) are ABI compatible between libstdc++-4.2 and libc++. These include operator new/delete and std-defined exception types.

libc++ is otherwise not ABI compatible with libstdc++. libc++ puts ABI incompatible types in an inlined namespace: std::__1. This causes *most* accidental ABI incompatibilities with libstdc++ to be caught at link time as the (for example) libstdc++ std::string and libc++ std::string will have different manglings.

Howard