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 6479A385840D; Mon, 27 Feb 2023 13:45:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6479A385840D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677505518;
	bh=QTgzuwoC7vWoe43xj0rVoPwVPLp/MvPHNYrvtpMjHKQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=P+iF8jh80iuWwNBTigYPccSFcBDqeSM2Rz6X6uF9mYq8FOSqulIwwOacpdRfu2lrH
	 R5c6o8ltw2CPfTUpsDinj8fJwpn/93SaNN26qaamxZ5PwdE8eOX8Sy+ndeHBmx5wY+
	 YKeoL31R122NzHVgCtHGoeZ9RiBYIUvlnsUKjBCE=
From: "aldyh 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 13:45:17 +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, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh 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: 
Message-ID: <bug-107561-4-TO1hojdKmK@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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #9)
> > Note I think there's still a bug in value_range (irange) here.=20
> > get_size_range
> > does
> >=20
> >   if (integral)
> >     {
> >       value_range vr;
> >=20
> >       query->range_of_expr (vr, exp, stmt);
> >=20
> >       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 ());
> >=20
> > and we have vr:
> >=20
> > (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
> >=20
> > 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
> >=20
> > // Return the highest bound of a range expressed as a tree.
> >=20
> > inline tree
> > irange::tree_upper_bound () const
> >=20
> > 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.
> >=20
> > I suppose irange::{min,max,tree_lower_bound,tree_upper_bound} miss "sup=
port"
> > for legacy_mode_p here.
>=20
> OTOH gimple-array-bounds.cc does
>=20
>   const value_range *vr =3D NULL;
>   if (TREE_CODE (low_sub_org) =3D=3D SSA_NAME)
>     {=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>       vr =3D get_value_range (low_sub_org, stmt);
>       if (!vr->undefined_p () && !vr->varying_p ())
>         {
>           low_sub =3D vr->kind () =3D=3D VR_RANGE ? vr->max () : vr->min =
();
>           up_sub =3D vr->kind () =3D=3D VR_RANGE ? vr->min () : vr->max (=
);
>         }
>=20
> so the bug is a documentation bug on min/max/lower/upper bound?!
>=20
> I'm policeing other uses of value_range right now.

Haven't looked at this yet, but min/max/lower/upper bound are broken and
inconsistent.  They give different results in legacy and the new irange API=
.=20
This was not by intent, but it crept in :/.  My fault.  I noticed this when
removing the legacy code for next stage1.=