https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123978
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/range-op.cc.jj 2026-01-02 09:56:10.289334455 +0100
+++ gcc/range-op.cc 2026-02-04 19:36:40.658365359 +0100
@@ -2437,12 +2437,10 @@ operator_widen_mult_unsigned::wi_fold (i
const wide_int &rh_lb,
const wide_int &rh_ub) const
{
- signop s = TYPE_SIGN (type);
-
wide_int lh_wlb = wide_int::from (lh_lb, wi::get_precision (lh_lb) * 2,
UNSIGNED);
wide_int lh_wub = wide_int::from (lh_ub, wi::get_precision (lh_ub) * 2,
UNSIGNED);
- wide_int rh_wlb = wide_int::from (rh_lb, wi::get_precision (rh_lb) * 2, s);
- wide_int rh_wub = wide_int::from (rh_ub, wi::get_precision (rh_ub) * 2, s);
+ wide_int rh_wlb = wide_int::from (rh_lb, wi::get_precision (rh_lb) * 2,
UNSIGNED);
+ wide_int rh_wub = wide_int::from (rh_ub, wi::get_precision (rh_ub) * 2,
UNSIGNED);
/* We don't expect a widening multiplication to be able to overflow but
range
calculations for multiplications are complicated. After widening the
seems to fix this miscompilation.
Though, as I said, I think there is still a bug for the s s -> u cases, and the
wi::get_precision (?h_?b) * 2 also looks wrong to me.
The WIDEN_MULT_EXPR etc. documentation doesn't talk that it has to be exactly
twice the precision, but at least twice.
So, shouldn't it be using TYPE_PRECISION (type) instead?
And, is operator_widen_plus_signed/operator_widen_plus_unsigned ever used?
