On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote:
> Yeah, having say __builtin_{clz,ctz,ffs,popcount,parity} variants which would
> be typegeneric and would allow say any normal integral or _BitInt type
> (or just unsigned versions thereof?) would be useful. Even without _BitInt
> we have the problem that we don't have builtins for __uint128_t.
>
> One question is if we should keep them UB on zero input or hardcode some
> particular
> behavior for clz/ctz. The backend defaults might not be appropriate, I
> think if we'd make it non-UB, using the precision of the type would be
> reasonable, whatever it is (__builtin_clzb ((unsigned _BitInt(126)) 0)
> might be 126 etc.).
FWIW the C2x stdbit.h operations all have defined semantics on special
cases, except for the stdc_bit_ceil operations (where there's an NB
comment on CD2 to be considered at next week's WG14 meeting requesting
defined semantics there as well). They're also all for unsigned
arguments. (Note there are also NB comments requesting removal of some of
the operations as duplicates or near-duplicates of others.)
The stdbit.h header does seem naturally to be something for libc, given
that (a) it has a lot of functions, not just type-generic macros, and (b)
the type-generic macros are generally easy to implement (at least for the
types supported in the standard) in a way that doesn't depend on any
compiler extensions (or even on _Generic, many of them can be implemented
just to call the function for unsigned long long). It makes sense in due
course for GCC to know the names there (after any get removed) as built-in
functions, but mapping in a header to existing __builtin_* is generally
easy until then.
--
Joseph S. Myers
jos...@codesourcery.com
