Bug 1261263 - Unsupport clang < 3.4. r?froydnj draft
authorMike Hommey <mh+mozilla@glandium.org>
Fri, 01 Apr 2016 11:55:29 +0900
changeset 346472 d1ea722351d0bc9c1d888c0805c2256f89ac7632
parent 346455 74d401683b5c4c99ac73e14a643480b15058b275
child 346473 ae0709a4832ca8e303dacb926da0c113363e2337
push id14391
push userbmo:mh+mozilla@glandium.org
push dateFri, 01 Apr 2016 06:06:10 +0000
reviewersfroydnj
bugs1261263, 1254861, 1254854, 654493
milestone48.0a1
Bug 1261263 - Unsupport clang < 3.4. r?froydnj In bug 1254861, we unsupported clang < 3.3, picking 3.3 essentially because that's the smallest version we had on automation. Bug 1254854 changed that, and the smallest version on automation is now 3.5. Now, the motivation to unsupport an old version of clang again is that recent versions don't have the problem with __float128 used in libstdc++ headers (bug 654493). In fact, starting with clang 3.4, the hack we have in place is not necessary. So let's just drop support for clang 3.3 instead of keeping that hack around longer. As mentioned in bug 1254854, Ubuntu 12.04 LTS has clang 3.4 packages.
build/autoconf/toolchain.m4
--- a/build/autoconf/toolchain.m4
+++ b/build/autoconf/toolchain.m4
@@ -221,21 +221,23 @@ if test "$GNU_CXX"; then
         AC_MSG_ERROR([Your toolchain does not support C++0x/C++11 mode properly. Please upgrade your toolchain])
     fi
 
     if test -n "$CLANG_CC"; then
         dnl We'd normally just check for the version from CC_VERSION (fed
         dnl from __clang_major__ and __clang_minor__), but the clang that
         dnl comes with Xcode has a completely different version scheme
         dnl despite exposing the version with the same defines.
-        dnl So instead of a version check, check for one of the C++11
-        dnl features that was added in clang 3.3.
-        AC_TRY_COMPILE([], [#if !__has_feature(cxx_inheriting_constructors)
-                            #error inheriting constructors are not supported
-                            #endif],,AC_MSG_ERROR([Only clang/llvm 3.3 or newer supported]))
+        dnl So instead of a version check, do a feature check. Normally,
+        dnl we'd use __has_feature, but there are unfortunately no C++11
+        dnl differences in clang 3.4. However, it supports the 2013-08-28
+        dnl draft of the ISO WG21 SG10 feature test macro recommendations.
+        AC_TRY_COMPILE([], [#if !__cpp_static_assert
+                            #error ISO WG21 SG10 feature test macros unsupported
+                            #endif],,AC_MSG_ERROR([Only clang/llvm 3.4 or newer supported]))
     fi
 
     AC_CACHE_CHECK([whether 64-bits std::atomic requires -latomic],
         ac_cv_needs_atomic,
         AC_TRY_LINK(
             [#include <cstdint>
              #include <atomic>],
             [ std::atomic<uint64_t> foo; foo = 1; ],
@@ -325,19 +327,19 @@ EOF
             if test "ac_cv_host_cxx0x_clang_workaround" = "no"; then
                 AC_MSG_ERROR([Your host toolchain does not support C++0x/C++11 mode properly. Please upgrade your toolchain])
             fi
             HOST_CXXFLAGS="$CXXFLAGS"
         elif test "$ac_cv_host_cxx0x_headers_bug" = "yes"; then
             AC_MSG_ERROR([Your host toolchain does not support C++0x/C++11 mode properly. Please upgrade your toolchain])
         fi
         if test "$host_compiler" = CLANG; then
-            AC_TRY_COMPILE([], [#if !__has_feature(cxx_inheriting_constructors)
-                                #error inheriting constructors are not supported
-                                #endif],,AC_MSG_ERROR([Only clang/llvm 3.3 or newer supported]))
+            AC_TRY_COMPILE([], [#if !__cpp_static_assert
+                                #error ISO WG21 SG10 feature test macros unsupported
+                                #endif],,AC_MSG_ERROR([Only clang/llvm 3.4 or newer supported]))
         fi
 
         CXXFLAGS="$_SAVE_CXXFLAGS"
         CPPFLAGS="$_SAVE_CPPFLAGS"
         CXX="$_SAVE_CXX"
     fi
 elif test "$GNU_CXX"; then
     HOST_CXXFLAGS="$HOST_CXXFLAGS $_ADDED_CXXFLAGS"