Re: improve clang support (1)

[Bruno Haible]

Hi Paul,

> > clang has __builtin_clz, __builtin_clzl, __builtin_clzll, also on Windows.
> > At least in versions >= 4.0.0.
> 
> Should this sort of thing be using __has_builtin if available? Something like 
> the following untested patch for count-leading-zeros.h (this is inspired by 
> how 
> verify.h does it):
> 
> diff --git a/lib/count-leading-zeros.h b/lib/count-leading-zeros.h
> index 7cf605a5f..622c22be2 100644
> --- a/lib/count-leading-zeros.h
> +++ b/lib/count-leading-zeros.h
> @@ -34,12 +34,22 @@ _GL_INLINE_HEADER_BEGIN
>   extern "C" {
>   #endif
> 
> +/* Whether __builtin_clz etc. work.  */
> +#if 3 < __GNUC__ + (4 <= __GNUC_MINOR__)
> +# define _GL_HAS_BUILTIN_CLZ 1
> +#elif defined __has_builtin
> +# define _GL_HAS_BUILTIN_CLZ (__has_builtin (__builtin_clz) \
> +                              && __has_builtin (__builtin_clzl) \
> +                              && __has_builtin (__builtin_clzll))
> +#else
> +# define _GL_HAS_BUILTIN_CLZ 0
> +#endif
> +

In theory your solution would be nicer. However,

1) When it comes to clang, I read [1][2]:
     "Prior to Clang 10, __has_builtin could not be used to detect most builtin
      pseudo-functions."

2) When it comes to compilers other than clang, we have this in 
gnulib-common.m4:

     /* Oracle Studio 12.6 mishandles may_alias despite __has_attribute OK.  */
     #if _GL_HAS_ATTRIBUTE (may_alias) && !defined __SUNPRO_C

   If they botched the usability of __has_attribute on their compiler, I expect
   the same thing regarding __has_builtin.

Yes, my current approach of testing each built-in with some test code with
various clang versions (and looking at the generated .s file) is more work than
just using __has_builtin. But I have higher confidence that it does what I 
expect
it to do.

Bruno

[1] https://clang.llvm.org/docs/LanguageExtensions.html
[2] 
https://stackoverflow.com/questions/42744425/clangs-has-builtin-doesnt-always-work