Bug 23046 - [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
Summary: [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.1.0
: P1 normal
Target Milestone: 4.1.0
Assignee: James A. Morrison
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 23968
  Show dependency treegraph
 
Reported: 2005-07-24 08:13 UTC by dank
Modified: 2005-11-08 21:16 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-08-04 18:43:23


Attachments
Reduced version of the code that exhibits the ICE (1.30 KB, text/plain)
2005-08-04 18:17 UTC, Kenny Smith
Details
vrp workaround (474 bytes, patch)
2005-10-11 06:36 UTC, James A. Morrison
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description dank 2005-07-24 08:13:06 UTC
While testing gcc-4.1-20050716, I ran across the error

bar.cc: In static member function 'static std::string
Blort::ConstructFullName(const std::string&, const std::vector<std::string,
std::allocator<std::string> >*, const std::string&, Blort::TwoValuedEnumType)':
bar.cc:1214: internal compiler error: in set_value_range, at tree-vrp.c:191

This was reproducible with just -O2; no other compiler flags were needed
to get the ICE.  (-O wasn't enough.)

It might be hard to provide a sanitized testcase,
but I can try if that's needed to track this down.
Comment 1 Andrew Pinski 2005-07-24 13:37:51 UTC
Hmm, nothing can be done without a testcase.
Comment 2 Andrew Pinski 2005-07-25 21:41:39 UTC
You might want to try delta:
 http://www.cs.berkeley.edu/~dsw/
I use the following script with delta to reduce stuff like this:
#!/usr/bin/python
# Using delta debugging on GCC input
#import psyco
#from psyco.classes import *
import commands
import string
import sys

# Invoke GCC
(status, output) = commands.getstatusoutput("/Users/pinskia/local.c/libexec/gcc/powerpc-apple-
darwin7.9.0/4.1.0/cc1plus -quiet  --param ggc-min-expand=0 --param ggc-min-heapsize=0 
-Wfatal-errors %s 2>&1" % sys.argv[1])

# Determine outcome
if status == 0:
  sys.exit(1)
elif string.find(output, "finish_compound_stmt") >= 0:
  sys.exit(0)
else:
  sys.exit(1)
Comment 3 Falk Hueffner 2005-07-29 22:20:31 UTC
waiting for testcase...
Comment 4 dank 2005-08-01 07:45:33 UTC
yup.  I hope to try out 'delta' soon.

BTW it appears to be x86_64 specific.  ppc and pentium didn't seem to show it.
Comment 5 Kenny Smith 2005-08-04 18:17:52 UTC
Created attachment 9432 [details]
Reduced version of the code that exhibits the ICE

This test case was reduced using delta (http://www.cs.berkeley.edu/~dsw/)
Comment 6 Andrew Pinski 2005-08-04 18:31:51 UTC
Confirmed, reducing a little further.
Comment 7 Andrew Pinski 2005-08-04 18:43:23 UTC
Reduced testcase:
enum eumtype { ENUM1, ENUM2 };
void g(const eumtype kind );
void f(long i);
void g(const eumtype kind)
{
  if ((kind != ENUM1) && (kind != ENUM2))
    f(kind);
}


--- the tree before VRP:
void g(eumtype) (kind)
{
  long int kind.0;

<bb 0>:
  if (kind_1 > 1) goto <L0>; else goto <L1>;

<L0>:;
  kind.0_2 = (long int) kind_1;
  f (kind.0_2);

<L1>:;
  return;

}
Comment 8 dank 2005-08-04 19:18:12 UTC
In general, once a ten-line testcase is found, do these get added
to the gcc regression testsuite as a matter of course?

We would be happy to submit patches to add these to the test suite, but 
we don't have copyright assignments in.  Let us know if we
should submit such patches anyway.
Comment 9 James A. Morrison 2005-08-04 19:22:50 UTC
 When the patch that fixes a bug is put into GCC the testcases go in as well.
Comment 10 Andrew Pinski 2005-08-04 19:23:34 UTC
(In reply to comment #8)
> In general, once a ten-line testcase is found, do these get added
> to the gcc regression testsuite as a matter of course?

In general once the fix is found, it will be added to the testsuite.
If it was already fixed, it will be added.
Comment 11 Diego Novillo 2005-08-04 19:24:39 UTC
Subject: Re:  [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191

On Thu, Aug 04, 2005 at 07:18:13PM -0000, dank at kegel dot com wrote:

> In general, once a ten-line testcase is found, do these get added
> to the gcc regression testsuite as a matter of course?
> 
No.  Only after a fix has been created for the failure.

> We would be happy to submit patches to add these to the test suite, but 
> we don't have copyright assignments in.  Let us know if we
> should submit such patches anyway.
> 
I don't know whether test cases require copyright assignments.
Comment 12 Diego Novillo 2005-08-05 13:30:46 UTC
Can't reproduce with mainline as of 2005-08-04.  Could you try again?
Comment 13 Diego Novillo 2005-08-05 13:36:12 UTC
Bah.  My compiler had checking disabled.  Sorry about that.
Comment 14 James A. Morrison 2005-08-05 14:49:08 UTC
I patched fold to change if (FOO > TYPE_MAX) or if (FOO < TYPE_MIN) to if (0)
and this fixes the ice.  I'll mail the patch when I get back from work tonight.
Comment 15 Diego Novillo 2005-08-05 16:46:49 UTC
(In reply to comment #14)
> I patched fold to change if (FOO > TYPE_MAX) or if (FOO < TYPE_MIN) to if (0)
> and this fixes the ice.  I'll mail the patch when I get back from work tonight.

That was my idea too, but it may not be as easy as it looks.  See Roger's
response to my message http://gcc.gnu.org/ml/gcc/2005-08/msg00169.html.

The problem now is that VRP will either need to treat the range as VARYING or do
some trickery to fold that conditional.  For 4.1 it is probably easier to just
set the range to VARYING.
Comment 16 Diego Novillo 2005-08-05 17:39:24 UTC
James has a potential fix for fold.  If that doesn't work, a simple change to
extract_range_from_assert_expr should provide a similar effect.  However, the
real problem in this PR is fold() not doing its job.
Comment 17 dank 2005-08-29 15:34:43 UTC
I think Jim's fold fix/workaround is at
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00371.html 
I'm using it locally now, and it seems at first glance
to get us past this problem.
Comment 18 Andrew Pinski 2005-10-09 15:44:28 UTC
I think this was decided that this was a front-end bug.
Comment 19 James A. Morrison 2005-10-11 06:36:32 UTC
Created attachment 9961 [details]
vrp workaround

There seems to be a combination of front-end and middle-end bugs that cause this.  The attached patch works around the problem in vrp by setting the range to VARYING.
Comment 20 Mark Mitchell 2005-10-31 04:15:45 UTC
This is a showstopper; ICE on simple, valid code.  We need to resolve what approach (es) to use to fix this and get it done.
Comment 21 Diego Novillo 2005-11-08 21:09:56 UTC
Subject: Bug 23046

Author: dnovillo
Date: Tue Nov  8 21:09:51 2005
New Revision: 106656

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106656
Log:
2005-11-08  James A. Morrison  <phython@gcc.gnu.org>
	    Diego Novillo  <dnovillo@redhat.com>

	PR 23046
	* tree-vrp.c (register_edge_assert_for): Do not register
	always-false predicates.

testsuite/

	PR 23046
	* g++.dg/tree-ssa/pr23046.C: New test.



Added:
    trunk/gcc/testsuite/g++.dg/tree-ssa/pr23046.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c

Comment 22 Diego Novillo 2005-11-08 21:16:13 UTC
Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00539.html