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 0A2F83858D32; Mon, 27 Feb 2023 09:56:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A2F83858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677491806;
	bh=9tcMMA8lgkqkhPAToGikLqVFeOWCZj93zCjSZ8ba8e8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=TW3m2p6kBOPAUj4bZKIJfELQERLNft81cy4vLd9bdK87CLMUtogzv3oSVLkbvk5KP
	 4pTdNIZ8gZnIBcWTDoYaDIBCy2BT+1KBtga8S/QjA9JsLDP0xWzHa9kQahrWyN57yq
	 n1vKR1ixc4EzMoFLWU4qpugt5IuSIfUqp3TwGD+M=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C  and
 [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow
 problem
Date: Mon, 27 Feb 2023 09:56:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: diagnostic, testsuite-fail
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: assigned_to bug_status
Message-ID: <bug-107561-4-eBh1DdkQjj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107561-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107561-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=3D107561

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot =
gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the testcase in comment#2 we end up with

<bb 2> [local count: 1073741824]:
MEM[(struct __as_base  &)&a] =3D{v} {CLOBBER};
a.m =3D 0;
_5 =3D operator new [] (0);
a.p =3D _5;
_2 =3D a.m;
if (_2 > 0)
  goto <bb 3>; [89.00%]
else
  goto <bb 5>; [11.00%]

and the code diagnosed is in the unreachable branch we cannot resolve as not
taken because 'operator new [] (0)' is thought to clobber 'a.m'.

We've been circling around improving alias analysis around new and delete
but since users can override them we threw the towel.

For the original testcase in g++.dg/pr71488.C we have

<bb 5> [local count: 214748368]:
*_51._M_size =3D 0;
_147 =3D operator new (0);

<bb 6> [local count: 214748368]:
*_51._M_data =3D _147;
_101 =3D *_51._M_size;
_99 =3D _101 * 8;
__builtin_memcpy (_147, _72, _99);

so again we fail to CSE '*_51._M_size' because of 'operator new (0)' but
also the diagnostic code simply assumes that size is at least 1 and
doesn't consider zero here for "reasons".

Note I think there's still a bug in value_range (irange) here.  get_size_ra=
nge
does

  if (integral)
    {
      value_range vr;

      query->range_of_expr (vr, exp, stmt);

      if (vr.undefined_p ())
        vr.set_varying (TREE_TYPE (exp));
      range_type =3D vr.kind ();
      min =3D wi::to_wide (vr.min ());
      max =3D wi::to_wide (vr.max ());

and we have vr:

(gdb) p vr
$13 =3D {<irange> =3D {<vrange> =3D {
      _vptr.vrange =3D 0x3693a30 <vtable for int_range<1u>+16>,=20
      m_kind =3D VR_ANTI_RANGE, m_discriminator =3D VR_IRANGE},=20
    m_num_ranges =3D 1 '\001', m_max_ranges =3D 1 '\001',=20
    m_nonzero_mask =3D <tree 0x0>, m_base =3D 0x7fffffffc8f0}, m_ranges =3D=
 {
    <integer_cst 0x7ffff68143f0>, <integer_cst 0x7ffff5e82090>}}
(gdb) p vr.dump (stderr)
[irange] unsigned int [0, 0][8, +INF]$17 =3D void

but vr.min () produces 1 and vr.max () produces 7, just as if it doesn't
interpret VR_ANTI_RANGE transparently here (if that's the intent?!).
At least

// Return the highest bound of a range expressed as a tree.

inline tree
irange::tree_upper_bound () const

suggests that.  Note that vr.num_pairs () produces 2 (because constant_p ())
but vr.m_num_ranges is 1 and tree_upper_bound uses m_num_ranges.

I suppose irange::{min,max,tree_lower_bound,tree_upper_bound} miss "support"
for legacy_mode_p here.

Either using int_range<2> or vr.lower_bound/upper_bound works to avoid this
issue.  Still it's fragile.  I suppose since 'value_range' is legacy
itself using int_range<2> is better here.  So I'm testing the following
to get rid of that legacy, plus get rid of ::min/max which are legacy as we=
ll.=