On Thu, 24 Oct 2024, Jakub Jelinek wrote:
> +@defbuiltin{@var{type} __builtin_stdc_rotate_left (@var{type} @var{arg1},
> @var{type} @var{arg2})}
The rotate count doesn't need to be the same type as the value rotated, so
saying @{type} for both is misleading.
> +The @code{__builtin_stdc_rotate_left} function is available only
> +in C. It is type-generic, the argument can be any unsigned integer
> +(standard, extended or bit-precise). No integral argument promotions are
> +performed on the argument. It is equivalent to
> +@code{(@var{type}) ((@var{arg1} << @var{arg2})
> +| (@var{arg1} >> ((-(unsigned) @var{arg2}) % @var{prec})))}
> +where @var{prec} is bit width of @var{type}, except that side-effects
> +in @var{arg1} and @var{arg2} are evaluated just once, and invokes undefined
> +behavior also if @var{arg2} >= @var{prec} even when @var{type} normally
> +promotes to @code{int}.
> +@enddefbuiltin
I think it's more appropriate for the built-in functions to handle
reducing the rotate count modulo the width of the type, matching the
<stdbit.h> functions. (Negative rotate counts are undefined behavior, but
arbitrary nonnegative values are OK. The rotate count can be of "signed
or unsigned integer type, or char" - so bool is OK as the type of the
rotate count, but a rotate count of enumerated type is undefined
behavior.)
--
Joseph S. Myers
josmy...@redhat.com
