https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #8)
> No fallout on x86 or aarch64.
>
> Of course using false instead of TYPE_SIGN (utype) is also possible and
> maybe clearer?
Well, wi::from_mpz doesn't take a sign argument. It's comment says
/* Returns X converted to TYPE. If WRAP is true, then out-of-range
values of VAL will be wrapped; otherwise, they will be set to the
appropriate minimum or maximum TYPE bound. */
wide_int
wi::from_mpz (const_tree type, mpz_t x, bool wrap)
I'm not sure if we really want saturating behavior here, so 'true' is
more correct? Note if we want an unsigned result we should pass utype here,
that might be the bug? So
begin = wi::from_mpz (utype, res, true);
?
The to_mpz args look like they could be mixing signs as well:
case vect_step_op_mul:
{
tree utype = unsigned_type_for (type);
init_expr = gimple_convert (stmts, utype, init_expr);
wide_int skipn = wi::to_wide (skip_niters);
wide_int begin = wi::to_wide (step_expr);
auto_mpz base, exp, mod, res;
wi::to_mpz (begin, base, TYPE_SIGN (type));
TYPE_SIGN (step_expr)?
wi::to_mpz (skipn, exp, UNSIGNED);
TYPE_SIGN (skip_niters) (which should be UNSIGNED I guess)?
