[Bug c/65875] New: internal compiler error with gcc 5.1

[Bug c/65875] New: internal compiler error with gcc 5.1

[megahallon at gmail dot com]

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

            Bug ID: 65875
           Summary: internal compiler error with gcc 5.1
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: megahallon at gmail dot com

Created attachment 35394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35394&action=edit
Preprocessed C file causing gcc crash

The enclosed file crashes gcc when compiled with -O2 as seen below. -O1 works.
It works with gcc 4.9.0.

$ gcc -v -O2 -c ~/gcc5.1bug.c

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O2' '-c' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1 -quiet -v
/home/hallon/gcc5.1bug.c -quiet -dumpbase gcc5.1bug.c -mtune=generic
-march=x86-64 -auxbase gcc5.1bug -O2 -version -o /tmp/cccJihQs.s
GNU C11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
    compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.2, MPC
version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
GNU C11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
    compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.2, MPC
version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2f2bc89784971300bbbb2cc329f649d8
src/sets/bitset.c: In function ‘mutbitset_iop_PyLongObject’:
src/sets/bitset.c:2021:20: warning: passing argument 1 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
                 from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘PyLongObject * {aka struct _longobject *}’ but argument is of
type ‘PyObject * {aka struct _object *}’
src/sets/bitset.c:2021:23: warning: passing argument 2 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
                 from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘Py_ssize_t * {aka long int *}’ but argument is of type ‘int *’
src/sets/bitset.c:2034:20: warning: passing argument 1 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
                 from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘PyLongObject * {aka struct _longobject *}’ but argument is of
type ‘PyObject * {aka struct _object *}’
src/sets/bitset.c:2034:23: warning: passing argument 2 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
                 from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘Py_ssize_t * {aka long int *}’ but argument is of type ‘int *’
src/sets/bitset.c: In function ‘sf_slice’:
src/sets/bitset.c:2985:1: internal compiler error: Segmentation fault
0x9bab0f crash_signal
    ../.././gcc/toplev.c:383
0xb73110 compare_values_warnv
    ../.././gcc/tree-vrp.c:1337
0xb7371c compare_values
    ../.././gcc/tree-vrp.c:1533
0xb833bc vrp_visit_phi_node
    ../.././gcc/tree-vrp.c:8879
0xad932d simulate_stmt
    ../.././gcc/tree-ssa-propagate.c:344
0xad9467 process_ssa_edge_worklist
    ../.././gcc/tree-ssa-propagate.c:422
0xada1fd ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**,
tree_node**), ssa_prop_result (*)(gphi*))
    ../.././gcc/tree-ssa-propagate.c:896
0xb7b394 execute_vrp
    ../.././gcc/tree-vrp.c:10367
0xb7b394 execute
    ../.././gcc/tree-vrp.c:10447
>From gcc-bugs-return-484559-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 24 12:28:12 2015
Return-Path: <gcc-bugs-return-484559-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 93291 invoked by alias); 24 Apr 2015 12:28:11 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 93212 invoked by uid 48); 24 Apr 2015 12:28:07 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65875] internal compiler error with gcc 5.1
Date: Fri, 24 Apr 2015 12:28: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: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: bug_status cf_reconfirmed_on cc component target_milestone everconfirmed
Message-ID: <bug-65875-4-M1tEFxU1Lc@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/msg02111.txt.bz2
Content-length: 703

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide875

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-24
                 CC|                            |mpolacek at gcc dot gnu.org
          Component|c                           |tree-optimization
   Target Milestone|---                         |5.2
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.  Started with r220164.

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org
            Summary|internal compiler error     |[5/6 Regression] ICE:
                   |with gcc 5.1                |Segmentation fault

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
int a, b, c, d, e, f, g;
void
fn1 ()
{
  long h = 0, i;
  if (g < 0)
    i = -g;
  for (; b;)
    for (; c;)
      if (e)
        h = 1;
  for (; f;)
    if (a)
      break;
  if (h > i)
    while (h > i)
      {
        d = 0;
        h--;
      }
}

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 35395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35395&action=edit
gcc5-pr65875.patch

Untested fix.  IMHO vrp_visit_phi_node was missing the vr_result VR_VARING
handling if the value range turned into varying only during update_value_range,
and also update_value_range wasn't telling the caller if it changed it into
varying late.

That said, the testcase has conditionally undefined variable, and checking
whether all the VRP decisions (first and second pass) are sane, would be nice,
Richard, could you please have a look?
E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it really
has just values 0 or 1, so should be ideally [0, 1].  Or that i has value range
[1, LONG_MAX] - it is conditionally undefined (that is ignored), and
conditionally negation of an int variable (only if that int variable is
negative).  The negated int variable is [1, +INF(OVF)] because INT_MIN might
overflow, perhaps if we really need to preserve the OVF flag, we have to use
[1, +INF(OVF)] again rather than just [1, 0x7fffffff] :(.

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 35395 [details]
> gcc5-pr65875.patch
> 
> Untested fix.  IMHO vrp_visit_phi_node was missing the vr_result VR_VARING
> handling if the value range turned into varying only during
> update_value_range, and also update_value_range wasn't telling the caller if
> it changed it into varying late.
> 
> That said, the testcase has conditionally undefined variable, and checking
> whether all the VRP decisions (first and second pass) are sane, would be
> nice, Richard, could you please have a look?
> E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it
> really has just values 0 or 1, so should be ideally [0, 1].  Or that i has
> value range [1, LONG_MAX] - it is conditionally undefined (that is ignored),
> and conditionally negation of an int variable (only if that int variable is
> negative).  The negated int variable is [1, +INF(OVF)] because INT_MIN might
> overflow, perhaps if we really need to preserve the OVF flag, we have to use
> [1, +INF(OVF)] again rather than just [1, 0x7fffffff] :(.

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.

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Apr 27 11:26:12 2015
New Revision: 222458

URL: https://gcc.gnu.org/viewcvs?rev=222458&root=gcc&view=rev
Log:
        PR tree-optimization/65875
        * tree-vrp.c (update_value_range): If in is_new case setting
        old_vr to VR_VARYING, also set new_vr to it.  Remove
        old_vr->type == VR_VARYING test.
        (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of
        SSA_PROP_INTERESTING if update_value_range returned true,
        but new range is VR_VARYING.

        * gcc.c-torture/compile/pr65875.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr65875.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Apr 27 12:21:17 2015
New Revision: 222461

URL: https://gcc.gnu.org/viewcvs?rev=222461&root=gcc&view=rev
Log:
        PR tree-optimization/65875
        * tree-vrp.c (update_value_range): If in is_new case setting
        old_vr to VR_VARYING, also set new_vr to it.  Remove
        old_vr->type == VR_VARYING test.
        (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of
        SSA_PROP_INTERESTING if update_value_range returned true,
        but new range is VR_VARYING.

        * gcc.c-torture/compile/pr65875.c: New test.

Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr65875.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/testsuite/ChangeLog
    branches/gcc-5-branch/gcc/tree-vrp.c

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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).

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 28 Apr 2015, jakub at gcc dot gnu.org wrote:

> 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].

Yeah, but we _explicitely_ special-case the +INF(OVF) case in the source
range assuming "arbitrary" overflow and thus use +INF(OVF) in the 
destination range as well.  Probably for warnings or whatever (I don't
like that OVF stuff anyway).

> 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).

But h also gets subtracted 1 as well.  It is the PHI node

h_2 = PHI <0(7), h_21(19)>

that causes the "issue" via the

  /* To prevent infinite iterations in the algorithm, derive ranges
     when the new value is slightly bigger or smaller than the
     previous one.  We don't do this if we have seen a new executable
     edge; this helps us avoid an overflow infinity for conditionals
     which are not in a loop.  If the old value-range was VR_UNDEFINED
     use the updated range and iterate one more time.  */
  if (edges > 0
      && gimple_phi_num_args (phi) > 1
      && edges == old_edges
      && lhs_vr->type != VR_UNDEFINED)

code as we go from

Visiting PHI node: h_2 = PHI <0(7), h_21(19)>
    Argument #0 (7 -> 8 executable)
        0: [0, 0]
    Argument #1 (19 -> 8 executable)
        h_21: [0, 0]
Meeting
  [0, 0]
and
  [0, 0]
to
  [0, 0]

to

Simulating statement (from ssa_edges): h_2 = PHI <0(7), h_21(19)>

Visiting PHI node: h_2 = PHI <0(7), h_21(19)>
    Argument #0 (7 -> 8 executable)
        0: [0, 0]
    Argument #1 (19 -> 8 executable)
        h_21: [0, 1]
Meeting
  [0, 0]
and
  [0, 1]
to
  [0, 1]
Intersecting
  [0, 9223372036854775806]
and
  [-INF, +INF]
to
  [0, 9223372036854775806]
Found new range for h_2: [0, 9223372036854775806]

as the range grows we "drop" to +INF - 1 (to give the next iteration
the chance to compute wheter it will overflow - previously we dropped
to +INF(OVF) immediately).

Yes, we can do some more iterating or instead of dropping right away
to +INF - 1 we could go towards +INF in log (+INF) steps.  It's all
a question about compile-time vs. accuracy in rare(?) cases.

Yes, if we have a way to statically compute a good range estimate
(like we try with adjust_range_with_scev) then that's of course
even better.  I don't see anything obvious here though.

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I meant in the first loop.
But we handle:
int b, c, e;

long
foo (int x, int y)
{
  long h = 0;
  for (b = 0; b < x; b++)
    for (c = 0; c < y; c++)
      if (e)
        h = 1;
  return h + 4;
}
correctly, it is only as soon as one of those loops turns into endless loop:
int b, c, e;

long
foo (int x, int y)
{
  long h = 0;
  for (b = 0; b < x; b++)
    for (c = 0; c < y;)
      if (e)
        h = 1;
  return h + 4;
}
that we lose track.  But, if it is only for endless loops, probably nothing to
worry about, the finite loops are much more important.