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 25D873858C2D; Mon, 14 Aug 2023 11:48:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25D873858C2D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1692013695;
	bh=/BfjYBNLagk9cKCaaXQ7LhfXqoy0N+WXz+r/27EPBfI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tTZ1iYDrskgONhYz4uzU8r54kw/26EXlMlL4oTD0adj0U9/SrYFTryPGcs48Gb6ES
	 tg0aA/7OOnDfXBy8ePGrM7Ssn7GYUsqJRfRuiEu5l+aaz2iZLiRCZK3ieRFtwTe3Qw
	 yRxIt++BXbGAEZUEizMJsuYqYv5UPZQd7NLjhzvE=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow
 erroneously elides null pointer checks and causes SIGSEGV on perf from
 linux-6.4.10
Date: Mon, 14 Aug 2023 11:48:14 +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: 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: P2
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: <bug-111009-4-yQFKQlrB8z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111009-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111009-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=3D111009

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
bool
operator_addr_expr::fold_range (irange &r, tree type,
                                const irange &lh,
                                const irange &rh,
                                relation_trio) const
{=20
  if (empty_range_varying (r, type, lh, rh))
    return true;

  // Return a non-null pointer of the LHS type (passed in op2).
  if (lh.zero_p ())
    r =3D range_zero (type);=20

not sure how this is called, but we can only derive this if the offset
is zero as well, definitely if targetm.addr_space.zero_address_valid,
but I think this is true in general.

  else if (!contains_zero_p (lh))
    r =3D range_nonzero (type);

and this is only true for TYPE_OVERFLOW_UNDEFINED (type), with
-fwrapv-pointer we could wrap to zero.

That is, it's _not_ GIMPLE undefined behavior to compute &0->bar.

It looks like without -fwrapv-pointer we elide the if (!a) check,
dereferencing it when dso && dso !=3D curr.  I suppose that looks reasonable
with a =3D &dso->maj, when dso !=3D 0 then a !=3D 0 unless ->maj wraps.=