On Sat, Mar 7, 2026 at 6:09 PM Collin Funk <[email protected]> wrote:
> Hi,
>
> While discussing Adhemerval's patch to use Gnulib's fts in glibc, there
> was a desire to avoid importing bitrotate.h which C2y has equivalent
> functionality for.
>
> I've attached patches adding the stdc_rotate_{left,right} macros and
> functions, but have not pushed them yet. It is probably worth noting
> that these functions are required to work when the shift is greater than
> the width of the word. This is not the case with the ones from
> bitrotate.h.
>
> Tested with GCC 4.8.5 which does not have the builtins for these
> functions and GCC 15 & 16 which do.
>
> I only modified stdbit_h.m4 slightly. It assumes that if stdbit.h exists
> it supports C2y or the subset provided by C23. If it only supports C23
> functionality, it will be generated. That feels reasonable to me, but
> wanted another set of eyes to look over it.
I don't know how deep you want to go down the rabbit hole with the self
tests. If you want thorough testing, then you might consider adding a test
for code generation. The rotates should be optimized down to a single
rotate left or rotate right instruction. You would test using objdump and
count rotl and rotr instructions. If I recall correctly, GCC 4.6 and below
have trouble recognizing the pattern and generating good code. See, for
example, <
https://github.com/weidai11/cryptopp/blob/master/TestScripts/cryptest.sh#L1309
>.
Another comment on the self tests... They only test `rotate imm`, like
`stdc_rotate_left_us, 0x5e1aU, 0` (with 0 being the immediate). You can
also issue a rotate based on a variable number of bits, but there are no
test cases for `rotate register` or `rotate memory`, where reg or mem might
come from a calculation.
Jeff
