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 68298384783D; Wed, 26 May 2021 13:17:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68298384783D
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/100499] Different results with -fpeel-loops
 -ftree-loop-vectorize options
Date: Wed, 26 May 2021 13:17:19 +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: 10.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: amker at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-100499-4-hcbq9lIMv1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-100499-4@http.gcc.gnu.org/bugzilla/>
References: <bug-100499-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 13:17:20 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100499

--- Comment #28 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #27)
> On Wed, 26 May 2021, aldyh at redhat dot com wrote:
>=20
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100499
> >=20
> > --- Comment #26 from Aldy Hernandez <aldyh at redhat dot com> ---
> > On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de
> > <gcc-bugzilla@gcc.gnu.org> wrote:
> >=20
> > > It's probably too strict for multiple_of_p which is fine with
> > > overflows that preserve modulo behavior.
> >=20
> > Could you provide an example?
>=20
> Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication
> and the query whether it's a multiple of 8.  Once you have no
> range for 'D.1234' you will signal overflow (correctly) but
> even then it's still a mutliple of 8.

Determining whether an arbitrary expression is a multiple of some number is=
 not
really something we can figure out via ranges. Well, that's not quite true.=
 If
we fully fleshed out the operations you care about, things like multiply or
shift you could get some results. presumably things like multiply by 2,4,8 =
and
16.. if we created correct multi-ranges for those, a cast of the high preci=
sion
range back to the original precision would yield an identical non-varying
range. and for non-multiples/unsupported values we'd get varying or somethi=
ng
not the same as the original value?.  This would only work if the original
value doesn't come out varying.    Although if its varying, maybe you dont =
care
and a match is ok anyway?    We could have may_overflow_p also return the
higher precision range for inspection if its true...=