Quantcast

Checking gcc/clang compiler version (was: OS X/Xcode build error: use of unknown builtin)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Checking gcc/clang compiler version (was: OS X/Xcode build error: use of unknown builtin)

Andy Gibbs
Hi,


I spotted the compiler version checking changes in commits [810d2932] and [8d3f485d] and thought I'd drop in with some thoughts.


I am not aware of everything that passes on this mailing list (I am only a sporadic reader) but I did try to go through and see where this change might have originated and I have read through (I hope all) of the related thread here: http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2017-February/071122.html


Yes, as spotted, clang is utterly useless when it comes to the version macros since (IMHO rather stupidly) the Apple version of clang gives at least a major version number higher than the underlying mainline clang version, which remains undisclosed by the compiler.  I guess this may be why there has been a move towards making standardised feature-checking macros since checking compiler versions was never a good way of doing this type of thing anyway.  Indeed, the post linked above gives details on how to do this, although I'd suggest a better, hopefully more future-proof way:

  #ifndef __has_builtin
  #define __has_builtin(x) 0
  #endif

  ...

  int sqlite3AddInt64(i64 *pA, i64 iB){
  #if GCC_VERSION>=5004000 || __has_builtin(__builtin_add_overflow)
    return __builtin_add_overflow(*pA, iB, pA);
  #else

  ...

Unfortunately, using the gcc version numbers is not suitable with clang because, while clang does indeed try to keep close compatibility with gcc, its reported gcc version number is fixed at version 4.2.1 (which is the point that Apple "branched" from using gcc to clang because of licensing issues, and this version number is maintained for compatibility with external libraries... I believe).


What this means is that using the gcc version number alone will actually disable the optimisations given by __builtin_{add|sub|mul}_overflow when compiled with clang.


Cheers,

Andy


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Checking gcc/clang compiler version (was: OS X/Xcode build error: use of unknown builtin)

Richard Hipp-3
On 2/20/17, Andy Gibbs <[hidden email]> wrote:
>
> What this means is that using the gcc version number alone will actually
> disable the optimisations given by __builtin_{add|sub|mul}_overflow when
> compiled with clang.
>

Yes.  And what this means is that I need to go back and implement a
rather more complicated set of #ifdefs to work around the issues with
clang.  I do intend to do that for the 3.18.0 release.  In the
meantime, several downstreams needed a quick and low-risk fix which
the https://www.sqlite.org/src/info/810d29320b853b3a check-in
provides.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...