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 EBABC386F46A; Tue, 27 Oct 2020 17:35:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EBABC386F46A
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/97457] [10/11 Regression] SVE: wrong code since
 r10-4752-g2d56600c
Date: Tue, 27 Oct 2020 17:35:51 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: everconfirmed assigned_to cc bug_status
 cf_reconfirmed_on
Message-ID: <bug-97457-4-YvCTKXLGSD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-97457-4@http.gcc.gnu.org/bugzilla/>
References: <bug-97457-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: Tue, 27 Oct 2020 17:35:52 -0000

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot=
 gnu.org
                 CC|                            |rsandifo at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-10-27

--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.or=
g> ---
Ugh.  This is yet another problem with calculating value ranges
for POLY_INT_CSTs.  We have:

  ivtmp_76 =3D ASSERT_EXPR <ivtmp_60, ivtmp_60 > POLY_INT_CST [9, 429496729=
4]>

where the VQ coefficient is unsigned but is effectively acting
as a negative number.  We wrongly give the POLY_INT_CST the range:

  [9, INT_MAX]

and things go downhill from there.

I guess this is the final nail in the coffin for doing VRP on
POLY_INT_CSTs. :-(  For other similarly exotic testcases we could
have overflow for any coefficient, not just those that could
be treated as contextually negative.

Let's see what the fallout is from removing the code...=