From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E40DE3858C62; Fri, 25 Aug 2023 12:35:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E40DE3858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1692966928; bh=nKnHBI6m7GIfIhsh/NKG7Mtfhq/vgz+J9US++aRpSLw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EzRbBJhL+Qzga0w4d+mDzuTXBj8P9ih26rSgFmEbjF2kvtBF4Dr2bOhevjesaGhpY UMujk6tm32Gc83RXgvy3vqKRfoCgh1B+WJHEGz2/K9Hk4pavQXV1gP4uvzQl/Ov2fu eR5fC5YPA566+JTiMDh2AY8VcoXMxqnMhbIy7wDc= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu Date: Fri, 25 Aug 2023 12:35:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end 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: 12.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111151 --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #3) > I think when overflow wraps we cannot do this transform at all, independe= nt > on the "sign" of 'c'. >=20 > Maybe >=20 > @@ -6970,8 +6972,11 @@ extract_muldiv_1 (tree t, tree c, enum tree_code > code, tree wide_type, >=20=20 > /* MIN (a, b) / 5 -> MIN (a / 5, b / 5) */ > sub_strict_overflow_p =3D false; > - if ((t1 =3D extract_muldiv (op0, c, code, wide_type, > - &sub_strict_overflow_p)) !=3D 0 > + if ((wide_type > + ? TYPE_OVERFLOW_UNDEFINED (wide_type) > + : TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0)))=20 > + && (t1 =3D extract_muldiv (op0, c, code, wide_type, > + &sub_strict_overflow_p)) !=3D 0 > && (t2 =3D extract_muldiv (op1, c, code, wide_type, > &sub_strict_overflow_p)) !=3D 0) > { but even when overflow is undefined we don't know whether we introduce additional overflow then. Consider MAX (INT_MIN, 0) * -1 where we compute 0 * -1 (fine) but after the transform we'd do MIN (INT_MIN * -1, 0) which isn't valid. And when overflow wraps consider MAX (UINT_MAX, 1) * 2 which will compute UINT_MAX * 2 =3D=3D 0 while MAX (UINT_MAX * 2, 1 * 2) will com= pute 2. Unless I'm missing something. What we'd need to know is whether the inner operations are known to not overflow/wrap (or whether they change sign consistently). But without range info we can't know this unless op0 and op1 are constants. So - scrap that whole sub-rule?=