[cfe-dev] [PATCH] Added support to libc++ for GCC 4.3, GCC 4.5, and most recent head of Clang.

[Howard Hinnant]

Thanks much for this work Jesse.  Please know that I won't be able to review this patch until next week as I am out of the office (but still within email range).

-Howard

On Aug 6, 2010, at 6:46 PM, Jesse Towner wrote:

> Okay, please disregard the original patch, there were some bugs that
> came up when I ran the test suite on OS X with GCC 4.2.1. This patch
> should take care of them.
> 
> Just to recap, I've tested it now on GCC 4.3.4, GCC 4.4.3, GCC 4.5.1,
> GCC 4.6 (head), and Clang/LLVM 2.8 (head) with and without-std=c++0x on
> Ubuntu 10.04 x86-64; GCC 4.2.1 and Clang/LLVM 2.8 (head) on OSX 10.6.4
> (both i386/x86-64); and GCC 4.2.1 on iOS 4.0.1 (both ARMv6/ARMv7).
> 
> Remarkably, many of the tests built and passed with Clang/LLVM 2.8 on
> OSX, although not quite as many as GCC was able to handle.
> 
> I had to add an additional tweak to the cmath header for OSX when
> building with Clang with -std=c++0x, as that flag disables the GNU
> extensions mode and defines __STRICT_ANSI__, and the current math.h
> headers with OSX/iOS (Xcode 3.2.3) don't bring in a number of the C99
> math functions when __STRICT_ANSI__ is defined.
> 
> Here's the revised change list:
> 
> - Better C++0x feature detection for both GCC and Clang (using Clang's
> __has_feature builtin preprocessor macro). Added explicit detection for
> defaulted and deleted functions.
> - Fix for Clang compilation error: Changed __config header to recognize
> Clang's support for builtin unicode character types char16_t and
> char32_t.
> - Fix for Clang compilation error: #undef'd __STRICT_ANSI__ in cmath on
> Apple platforms to get all C99 function symbols pulled in. Used clang's
> new push_macro/pop_macro pragmas to restore __STRICT_ANSI__ afterward.
> - Fixes for GCC 4.3: Moved a lot of the GCC 4.3 C++0x feature support up
> to 4.4 for now in __config header, as although they exist in 4.3,
> various parts of libc++ assumed that they were fully implemented or
> implied the existence of other C++0x features. Also fine-tuned some
> preprocessor conditional checks in iterator, memory, thread, type_traits
> and utility headers to account for this. It'd probably be possible to
> rewrite a bunch of the offending areas (things that use variadic
> templates and auto/decltype) so that they could work in 4.3.
> - Fix for GCC 4.5 compilation error: Added conditional operator
> overloads for comparing generic pointer types against nullptr_t to
> handle stricter/more fickle template argument type matching in this
> compiler.
> - Fix for GCC 4.5 compilation error: Changed both std::move and
> std::forward C++0x-specific implementations to explicitly cast the
> object to an r-value reference type as GCC 4.5 implements the new
> wording for move semantics and rvalue references
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html).
> This didn't introduce warning messages in any of the other compilers I
> tested with, so not sure what compiler was originally causing the issues
> here.
> - Fix for GCC 4.6: Changed libc++ to use GCC 4.6's builtin nullptr
> keyword.
> 
> Cheers,
> 
> Jesse
> <libcxx_compiler_support_v2.patch>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev