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 E52983858D1E; Tue, 31 Jan 2023 08:05:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E52983858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675152358;
	bh=HAFnIvb+i8YO1hHEnrVwNL54imdFeWKcY2SoVzNqFHw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=NzvFOxr0YdSMXmUNHptRzu0Dp2CaRdfYPtnJdrZCpmo5NP8gqb+fxFk7qwLohZU7G
	 ss5qhuYjKMoRtwUB9/60xJT9ecnjwSVvUMz6GnRve6/Dbm9wB0sXLZOpFpZr0u4eCP
	 Le+nRkBueLNCiMgpVc30JLPkkbLMtGJIDqDfQRvY=
From: "shaohua.li at inf dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/108481] [13 Regression] UBsan missed a signed integer
 overflow
Date: Tue, 31 Jan 2023 08:05:58 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: needs-bisection, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: shaohua.li at inf dot ethz.ch
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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108481-4-IX4UmmcHMj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108481-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108481-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=3D108481

--- Comment #4 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
(In reply to Andrew Pinski from comment #2)
>       i =3D i - 6822162149299574294;
>=20
> Is not being invoked on the executable code.
>=20
> If we look at look at the original code:
>=20
>=20
>     if ((i * (unsigned long)7 <=3D 1) << j)
>       ;
>     else {
>       i =3D i - 6822162149299574294;
>       if (j) {
>         if (*g)
>           break;
>         continue;
>       }
>       return 8;
>     }
> ...
>   return h;
>=20
> The only path where the undefined behavior even matters is inside the path
> that had continue in it. Which is where the subtraction is pushed to now.
>=20
> I don't know if we should declear this as a valid thing to do or not.

When I compiled the source code with `-O1 -fsanitize=3Dundefined` and then =
used
gdb to check the execution trace of the binary, I indeed observed that `i =
=3D i -
6822162149299574294` was executed.=