From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 2153F3858D37; Wed, 20 Mar 2024 08:01:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2153F3858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1710921675;
	bh=Mgxw158sD0TAGBGR0mVZ9Z4QMnOsd+0ev64TgGi8WQE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=eg2+y5v7LOtUCWhAZlIQMccbGOxg57VCqagqGhGCJEGlfcl1fOuK5C0/5sNlUFIr2
	 J2qN5JtA1/WowDJ6MXx7VQExV5Fw0uxHDypG1GsGtNIRSvKwQR0iT3A3V6bzO2p7wy
	 I64j6N9Jhw7LVuk+jPHW043okcTDbOJBCTy6Ul/Y=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114396] [14 Regression] Vector: Runtime
 mismatch at -O2 with -fwrapv
Date: Wed, 20 Mar 2024 08:01:07 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: needs-bisection, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114396-4-sRzY4Tn2UQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114396-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114396-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114396

--- 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.
>=20
> 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 =3D 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 =3D unsigned_type_for (type);
        init_expr =3D gimple_convert (stmts, utype, init_expr);
        wide_int skipn =3D wi::to_wide (skip_niters);
        wide_int begin =3D 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)?=