Bug 105597 - [13 Regression] ice in type, at value-range.h:223
Summary: [13 Regression] ice in type, at value-range.h:223
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 13.0
: P3 normal
Target Milestone: 13.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2022-05-13 17:03 UTC by David Binderman
Modified: 2022-10-28 20:19 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2022-05-13 00:00:00


Attachments
C source code (49.78 KB, text/x-csrc)
2022-05-13 17:03 UTC, David Binderman
Details
proposed patch (558 bytes, patch)
2022-05-13 17:14 UTC, Andrew Macleod
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2022-05-13 17:03:09 UTC
Created attachment 52972 [details]
C source code

For the attached C code, recent gcc trunk with flag -O2 does this:

during GIMPLE pass: vrp
mgpswindows.c: In function 'mgps_initpsdevice':
mgpswindows.c:48:5: internal compiler error: in type, at value-range.h:223
   48 | int mgps_initpsdevice()
      |     ^~~~~~~~~~~~~~~~~
0x1c9b178 irange::type() const
    ../../trunk.git/gcc/value-range.h:223
0x1c9b178 operator_minus::lhs_op1_relation(irange const&, irange const&, irange const&, tree_code) const
    /home/dcb/gcc/working/gcc/../../trunk.git/gcc/range-op.cc:1349

I will have my usual go at reducing the code and finding a range of git
hashes where the problem starts.
Comment 1 David Binderman 2022-05-13 17:07:30 UTC
The bug seems to have started recently, between git hash 5b2a24ebfc0b2b4c
and 98e475a8f58ca3ba, a distance of 111 commits.
Comment 2 Andrew Macleod 2022-05-13 17:14:39 UTC
Created attachment 52973 [details]
proposed patch

Fix is here.  Testing in progress.
 
A reduced testcase would be helpful for the testsuite when I check it in.
Comment 3 David Binderman 2022-05-13 17:21:01 UTC
Reduced C code seems to be:

typedef struct {
  int allocated;
} vvec;
int vvneeds_want, mgpssort;
void vvinit(vvec *v, int minelems) { v->allocated = -minelems; }
void vvneeds(vvec *v, int needed) {
  if (needed > v->allocated)
    if (v->allocated < 0)
      ;
    else {
      int next = v->allocated + (v->allocated >> 1);
      vvneeds_want = next;
    }
}
void mgpssort_1() {
  vvinit(&mgpssort, mgpssort_1);
  vvneeds(&mgpssort, mgpssort_1);
}
Comment 4 Marek Polacek 2022-05-13 17:21:54 UTC
Confirmed then.
Comment 5 GCC Commits 2022-05-13 18:41:30 UTC
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:e97e99296505e6015bc9e281364818bb89ca8a49

commit r13-449-ge97e99296505e6015bc9e281364818bb89ca8a49
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Fri May 13 13:11:18 2022 -0400

    Check operand for type, not LHS.
    
    When folding, the LHS has not been set, so we should be checking the type of
    op1.  We should also make sure op1 is not undefined.
    
            PR tree-optimization/105597
            gcc/
            * range-op.cc (operator_minus::lhs_op1_relation): Use op1 instead
            of the lhs and make sure it is not undefined.
            gcc/testsuite/
            * gcc.dg/pr105597.c: New.
Comment 6 Andrew Macleod 2022-05-13 18:42:06 UTC
fixed.