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
