https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117456
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:02fff24e2c6d4affc47dac1433b2fb182dadd4db commit r15-5472-g02fff24e2c6d4affc47dac1433b2fb182dadd4db Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Nov 19 20:34:36 2024 +0100 c: Fix up __builtin_stdc_rotate_{left,right} lowering [PR117456] Apparently the middle-end/expansion can only handle {L,R}ROTATE_EXPR on types with mode precision, or large/huge BITINT_TYPE. So, the following patch uses the rotate exprs only in those cases where it can be handled, and emits code with shifts/ior otherwise. As types without mode precision including small/medium BITINT_TYPE have unlikely power of two precision and TRUNC_MOD_EXPR is on many targets quite expensive, I chose to expand e.g. __builtin_stdc_rotate_left (arg1, arg2) as ((tem = arg1, count = arg2 % prec) ? ((tem << count) | (tem >> (prec - count))) : tem) rather than (((tem = arg1) << (count = arg2 % prec)) | (tem >> (-count % prec)) (where the assignments are really save_exprs, so no UB), because I think another TRUNC_MOD_EXPR would be more costly in most cases when the shift count is non-constant (and when it is constant, it folds to 2 shifts by constant and ior in either case). 2024-11-19 Jakub Jelinek <ja...@redhat.com> PR c/117456 gcc/c/ * c-parser.cc (c_parser_postfix_expression): Use LROTATE_EXPR or RROTATE_EXPR only if type_has_mode_precision_p or if arg1 has BITINT_TYPE with precision larger than MAX_FIXED_MODE_SIZE. Otherwise build BIT_IOR_EXPR of LSHIFT_EXPR and RSHIFT_EXPR and wrap it into a COND_EXPR depending on if arg2 is 0 or not. * c-fold.cc (c_fully_fold_internal): Check for suppression of -Wshift-count-overflow warning. gcc/testsuite/ * gcc.dg/builtin-stdc-rotate-4.c: New test.
