[cfe-dev] Using C++11 in clang/tools/extra

[Howard Hinnant]

On Nov 29, 2012, at 3:09 AM, Chandler Carruth <chandlerc at google.com> wrote:

> On Wed, Nov 28, 2012 at 9:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Nov 28, 2012 at 7:39 PM, Chandler Carruth <chandlerc at google.com> wrote:
>>> On Wed, Nov 28, 2012 at 7:28 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>>> On Nov 28, 2012, at 10:45 AM, Marshall Clow wrote:
>>>>> On Nov 28, 2012, at 7:15 AM, "Vane, Edwin" <edwin.vane at intel.com> wrote:
>>>>>> 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

> 
> 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....
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev