clang claim to be gcc 4.8.1 instead of 4.2.1

[Yaron Keren]

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 <yaron.keren at gmail.com>:

> 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 <thakis at chromium.org>:
>
>> 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 <yaron.keren at gmail.com>
> 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
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141113/d3f435da/attachment.html>