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 CE0E33858D35; Tue, 31 Jan 2023 04:00:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CE0E33858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675137658;
	bh=K9wIeuA0MgWDi82Zvri7/5kiuIXydsGsSrMpV43RbFo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=eNuRkF0TRH+0Q3ubBCfZBsvzvgIW+RinhYyo7XQ8mA9izatphfI/WNBI1NS6K1G2w
	 ZzjLbYHcBCyMjUFu4kjMQgge0P+DyI+K1mt9Kpra0r+B6BG8+rhonwrMjsSnXySIQ6
	 nhiL/ZW504DIAUA5afathn/x5ZCtdA75MFkQqJ+M=
From: "pinskia at gcc dot gnu.org" <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 04:00: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: pinskia 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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108481-4-584m1V3NBY@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 #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

This is what the IR looks in the end:
  _27 =3D _17 << _20;
  if (_27 !=3D 0)
    goto <bb 12>; [50.00%]
  else
    goto <bb 9>; [50.00%]

  <bb 9> [local count: 1560331071]:
  if (_20 !=3D 0)
    goto <bb 10>; [94.50%]
  else
    goto <bb 13>; [5.50%]

  <bb 10> [local count: 1474512859]:
  _30 =3D a;
  if (_30 !=3D 0)
    goto <bb 13>; [67.00%]
  else
    goto <bb 11>; [33.00%]

  <bb 11> [local count: 486589241]:
  i_28 =3D .UBSAN_CHECK_SUB (i_13, 6822162149299574294);

  <bb 12> [local count: 2046920311]:
  # i_34 =3D PHI <i_13(8), i_28(11)>
  (Loop back)
...

  <bb 13> [local count: 1073741830]:
  return 0;

As you can see the only path where the ubsan_check_sub is executed is right
before the continue which is seems like a very valid thing to do.=