Well, this was fixed in Boost 1.5.7 released ten days ago: // However, using the GCC version number fails when the compiler is clang since this // only ever claims to emulate GCC-4.2, see https://svn.boost.org/trac/boost/ticket/7473 // for a long discussion on this issue. What we can do though is use clang's __has_include // to detect the presence of a C++11 header that was introduced with a specific GCC release. // We still have to be careful though as many such headers were buggy and/or incomplete when // first introduced, so we only check for headers that were fully featured from day 1, and then // use that to infer the underlying GCC version:
2014-11-13 6:50 GMT+02:00 Yaron Keren <[email protected]>: > The doc say that clang still does not > support __builtin_va_arg_pack/__builtin_va_arg_pack_len: > > > http://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet > > My use case for the newer gcc version is boost config, which conditions > its TR1 headers based on gcc version. clang claim to be 4.2 may introduce a > difference when switching to clang, since gcc 4.8 will use the libstdc++ > boost headers while switching to clang will use the boost headers. In one > complex case actually fails to compile with #include <something> failing, > where it seems the boost code does not expect <something> to exist since it > did not in libstdc++ of gcc 4.2 at all while it does exist in libstdc++ of > gcc 4.9 which is the real version. > > Other libraries than boost dont have their own TR1 replacement headers and > will probably have reduced functionality with clang = gcc 4.2. > > It may be better have clang pretend gcc 4.8 and patch the glibc > conditional rather than all other libraries? > > Examples from boost config: > > // C++0x headers in GCC 4.3.0 and later > // > #if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 3) || > !defined(__GXX_EXPERIMENTAL_CXX0X__) > # define BOOST_NO_CXX11_HDR_ARRAY > # define BOOST_NO_CXX11_HDR_TUPLE > # define BOOST_NO_CXX11_HDR_UNORDERED_MAP > # define BOOST_NO_CXX11_HDR_UNORDERED_SET > # define BOOST_NO_CXX11_HDR_FUNCTIONAL > #endif > > // C++0x headers in GCC 4.4.0 and later > // > #if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4) || > !defined(__GXX_EXPERIMENTAL_CXX0X__) > # define BOOST_NO_CXX11_HDR_CONDITION_VARIABLE > # define BOOST_NO_CXX11_HDR_FORWARD_LIST > # define BOOST_NO_CXX11_HDR_INITIALIZER_LIST > # define BOOST_NO_CXX11_HDR_MUTEX > # define BOOST_NO_CXX11_HDR_RATIO > # define BOOST_NO_CXX11_HDR_SYSTEM_ERROR > # define BOOST_NO_CXX11_SMART_PTR > #else > # define BOOST_HAS_TR1_COMPLEX_INVERSE_TRIG > # define BOOST_HAS_TR1_COMPLEX_OVERLOADS > #endif > > #if (!defined(_GLIBCXX_HAS_GTHREADS) || > !defined(_GLIBCXX_USE_C99_STDINT_TR1)) && > (!defined(BOOST_NO_CXX11_HDR_CONDITION_VARIABLE) || > !defined(BOOST_NO_CXX11_HDR_MUTEX)) > # define BOOST_NO_CXX11_HDR_CONDITION_VARIABLE > # define BOOST_NO_CXX11_HDR_MUTEX > #endif > > ... > > > > > > 2014-11-13 1:04 GMT+02:00 Nico Weber <[email protected]>: > >> This was discussed in this thread >> http://marc.info/?t=133682946900003&r=1&w=2 People were generally >> supportive of the idea, but it was deemed very hard to get glibc to build >> with this ( http://marc.info/?l=cfe-dev&m=133717592322519&w=2 ) and the >> benefit of doing this wasn't seen as very big in the end. > > > On Wed, Nov 12, 2014 at 2:55 PM, Yaron Keren <[email protected]> > wrote: > >> gcc 4.2.1 is really old from 2008. Some configuration headers such as >> boost "libstdcpp3.hpp" behave differently for pre-gcc 4.3 or later. >> >> gcc 4.8.1 is more recent, reasonable claim for clang. >> >> I had tried going for 4.9.1 but encountered a problem with intrinsics in >> mingw 4.9.1 intrin.h which are treated differently for gcc 4.9 or later: >> >> * On GCC 4.9 we may always include those headers. On older GCCs, we may >> do it only if CPU >> * features used by them are enabled, so we need to check macros like >> __SSE__ or __MMX__ first. >> */ >> #if __MINGW_GNUC_PREREQ(4, 9) >> #define __MINGW_FORCE_SYS_INTRINS >> #endif >> ... >> >> this does not work correctly with clang since the headers try to use SSE3 >> instructions without __SSE3__ being defined and fail. >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
