https://gcc.gnu.org/g:0e4fe83c0679b656123832140964dc1ecef77d1c
commit r17-1391-g0e4fe83c0679b656123832140964dc1ecef77d1c Author: Richard Sandiford <[email protected]> Date: Sat Jun 6 13:59:12 2026 +0100 optabs: Fix can_open_code_p handling of abs and neg As noticed by Jakub in the discussion about yesterday's bswap changes. The change should be a no-op in practice since AND and XOR don't have libgcc2 functions; we'd always split into word-mode operations instead. Even so, it doesn't make conceptual sense for can_open_code_p to call can_implement_p. The fact that this seems to be a recurring blind spot for me suggests that I didn't choose good names... gcc/ * optabs-query.cc (can_open_code_p): Use can_open_code_p rather than can_implement_p when testing for AND and XOR. Diff: --- gcc/optabs-query.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/optabs-query.cc b/gcc/optabs-query.cc index 8226356c7d40..58842e40ed6b 100644 --- a/gcc/optabs-query.cc +++ b/gcc/optabs-query.cc @@ -837,7 +837,7 @@ can_open_code_p (optab op, machine_mode mode) if ((op == neg_optab || op == abs_optab) && is_a<scalar_float_mode> (GET_MODE_INNER (mode), &fmode) && get_absneg_bit_mode (op, mode, fmode, &bitpos).exists (&new_mode) - && can_implement_p (op == neg_optab ? xor_optab : and_optab, new_mode)) + && can_open_code_p (op == neg_optab ? xor_optab : and_optab, new_mode)) return true; scalar_int_mode int_mode;
