[Bug tree-optimization/23476] New: [4.1 Regression] ICE in VRP, remove_range_assertions

[Bug tree-optimization/23476] New: [4.1 Regression] ICE in VRP, remove_range_assertions

[pinskia at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

Testcase:
int h(int);

static inline int f(int t, const int i)
{
  _Bool a = i < t;
  if (a)
    return h(t);
  return 9;
}

int g(int t)
{
  return f(t, 0x7FFFFFFF);
}

Compile with -O2 -fno-tree-copy-prop, and you will get an ICE:
t.c: In function ‘g’:
t.c:12: internal compiler error: in remove_range_assertions, at tree-vrp.c:2767
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

This most likely can be produced with a much larger source but I cannot find it right now as copy-prop 
does nothing interesting except for calling fold on all the statements which is just a waste of time.

-- 
           Summary: [4.1 Regression] ICE in VRP, remove_range_assertions
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-19 06:19 -------
Honza and Diego, this is the VRP bug which Honza was talking about which he found working on his 
SSA based inliner.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org, hubicka at gcc dot gnu
                   |                            |dot org
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-19 06:24 -------
Ignore the comment about fold, copy prop is doing its job.

Also here is a testcase which can be repduced with a simple -O2 so this is definitely a regression now 
and not just a latent bug waiting to be exposed by other changes:
int h(int);
int t;
static inline int f(const int i)
{
  int tt = i;
  _Bool a = i < t;
  if (a)
    return h(t);
  return 9;
}
int g(void)
{
  return f(0x7FFFFFFF);
}

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[dnovillo at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dnovillo at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[dnovillo at gcc dot gnu dot org]

------- Additional Comments From dnovillo at gcc dot gnu dot org  2005-08-19 13:27 -------

Testing patch.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-08-19 18:09 -------
Subject: Bug 23476

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dnovillo@gcc.gnu.org	2005-08-19 18:08:56

Modified files:
	gcc            : ChangeLog tree-cfgcleanup.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: pr23476.c 

Log message:
	PR 23476
	* tree-cfgcleanup.c (cleanup_control_expr_graph): Fold the
	conditional expression before testing its value.
	
	PR 23476
	* gcc.c-torture/compile/pr23476.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9783&r2=2.9784
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfgcleanup.c.diff?cvsroot=gcc&r1=2.5&r2=2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5938&r2=1.5939
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr23476.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[dnovillo at gcc dot gnu dot org]

------- Additional Comments From dnovillo at gcc dot gnu dot org  2005-08-19 18:10 -------

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01150.html.

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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2005-08-20 15:27 -------
My apologies for adding a comment to an already resolved PR, but I've some
follow-up thoughts on Diego's recent solution to this regression.  From a
high-level perspective, it would probably be more efficient to require that
conditions are always folded as an invariant of our tree-ssa data structures. 
It's better to fold a conditional once when it is constructed/modified,
rather than need to call fold on it each time it is examined.  Some places
that build/modify conditionals may know that fold doesn't need to be (or
has already been) called, whilst requiring the many places that examine CFGs
to call fold themselves is pessimistic.  This also fits well with our recent
"folded by construction" philosophy, using fold_buildN instead of build.

I appreciate that this a meta-issue, and Diego's fix is fine for this problem,
but ultimately I think that placing stricter invariants on our data structures
will reduce the number of unnecessary calls to fold, and speed up the compiler.
Eventually, most calls to build* should be fold_build*, and it should rarely
be necessary to call fold() without a call to build (or in place modification
of a tree).  But perhaps there a valid tree-ssa reasons why this shouldn't be
a long-term goal?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at eyesopen dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476