From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-484807-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 86110 invoked by alias); 28 Apr 2015 07:51:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 86037 invoked by uid 48); 28 Apr 2015 07:51:02 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
Date: Tue, 28 Apr 2015 07:51:00 -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: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65875-4-LUvDpeZr93@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65875-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65875-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg02359.txt.bz2

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> For h we get into the loop PHI handling code which drops to INF-1 if it
> iterates
> "too much".  The rest probably ripples down from that.
> 
> I can't see where that [1, 0x7ffffff] issue happens.

Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump:
  <bb 2>:
  g.0_9 = g;
  if (g.0_9 < 0)
    goto <bb 3>;
  else
    goto <bb 9>;

  <bb 3>:
  _12 = -g.0_9;
  i_13 = (long int) _12;
  goto <bb 9>;

and

Visiting statement:
_12 = -g.0_25;
Found new range for _12: [1, +INF(OVF)]
marking stmt to be not simulated again

Visiting statement:
i_13 = (long int) _12;
Found new range for i_13: [1, +INF(OVF)]
marking stmt to be not simulated again

The point was that the cast from 32-bit signed to 64-bit signed also should
imply that the value is not bigger than INT_MAX, and that is what we would do
if range for _12 was say [1, 0x7fffffff].

And for h, the point was that if only constants are assigned to the variable in
a loop, then no matter how many iterations the loop has, the resulting value
will only be one of the constants (thus smallest range covering those).
Or in this particular case, as the h = 1 assignments is only in endless loop,
we could have computed just [0, 0] (but that is probably too rare to care
about).