Re: [RFC] Add stdckdint.h header for C23

[Joseph Myers <joseph@codesourcery.com>]

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
joseph@codesourcery.com