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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
