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 D2E503858D34; Mon, 15 Apr 2024 03:43:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D2E503858D34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713152609;
	bh=rzoa6x2UQXz7PG/d1MFWB3PwxqtH9ZbSYQIMMb3wjO4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=v8n/IlphTUuCbQZIC0dgqrujXcoBrmvsYAW2BzrUCOZdgp/VrSDanXe92aEEJWsA/
	 ccyUeEj2WotIwmeCQQAA+GMO6nFDGVyp5ImwA2732DhqRKO+DQKiWt6cYbDvKd87az
	 lsQ4su+gnLtDJPor/njBCz12AiJBG+f6U1WOrS2I=
From: "lin1.hu at intel dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/114700] middle-end optimization generates causes
 -fsanitize=undefined not to happen in some cases
Date: Mon, 15 Apr 2024 03:43:29 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: lin1.hu at intel dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114700-4-zsUNHWRvDq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114700-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114700-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=3D114700

--- Comment #17 from Hu Lin <lin1.hu at intel dot com> ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Hu Lin from comment #11)
> > I think it doesn't mean that's not a bug with -ftrapv, it should preser=
ve
> > all overflow traps. Because it doesn't work, we use -fsanitize=3Dundefi=
ned
> > instead of it.
> >=20
> > refer: Gcc's trapv is known not always to work correctly.
>=20
> No, -ftrapv isn't a debugging tool.  There is no overflow in the expressi=
on
> that GCC actually evaluates (into which the expression has been optimized=
).
> If you have overflow in an expression that is never used, GCC with -ftrapv
> will also
> eliminate it as unused and won't diagnose the trap.
> -fsanitize=3Dundefined behaves in that case actually the same with -O1 and
> higher (intentionally, to decrease the cost of the sanitization).  So, one
> needs to use -O0 -fsanitize=3Dundefined to get as many cases of UB in the
> program diagnosed as possible.

OK, that look like GCC's -ftrapv is not the same as clang's. Then my added
condition should be (optimize || !TYPE_OVERFLOW_SANITIZED (type)).=20

> When a pattern already has one if, can't you just add that to the preexis=
ting if rather than adding yet another one.

I made a mistake on this line, it should be
+   (if (!TYPE_OVERFLOW_SANITIZED (type))
     (if (!ANY_INTEGRAL_TYPE_P (type)
         || TYPE_OVERFLOW_WRAPS (type))
      (negate (view_convert @1))
      (view_convert (negate @1))))

I can't just modify the preexisting if, the optimization shouldn't be used =
with
-fsanitize=3Dundefined.=