[Bug middle-end/38572] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[Bug middle-end/38572] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bero at arklinux dot org]

While compiling xulrunner with yesterday's gcc 4.4 svn rev 142782:

c++ -o jsparse.o -c -I./dist/include/system_wrappers -include
./config/gcc_hidden.h -DAVMPLUS_IA32 -DAVMPLUS_UNIX -DAVMPLUS_LINUX
-DFEATURE_NANOJIT -DJS_TRACER -DOSTYPE=\"Linux2.6.28-0.rc7\" -DOSARCH=Linux
-DEXPORT_JS_API  -DJS_USE_SAFE_ARENA  -I. -I.  -I./dist/include  
-I./dist/include/js -I/usr/include/nspr -I/sdk/include -I.    -fPIC   -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-long-long -pedantic -m32 -O2 -march=i686 -fomit-frame-pointer -fweb
-frename-registers -mmmx
-Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu,--sort-common
-msse -fvisibility-inlines-hidden -fno-strict-aliasing -fshort-wchar -pthread
-pipe  -DNDEBUG -DTRIMMED -m32 -O2 -march=i686 -fomit-frame-pointer -fweb
-frename-registers -mmmx
-Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu,--sort-common
-msse   -DMOZILLA_CLIENT -include ./mozilla-config.h -Wp,-MD,.deps/jsparse.pp
jsparse.cpp
jsparse.cpp: In function 'JSParseNode* Statement(JSContext*, JSTokenStream*,
JSTreeContext*)':
jsparse.cpp:2764: warning: suggest parentheses around '&&' within '||'
jsopcode.cpp: In function 'jsbytecode* Decompile(SprintStack*, jsbytecode*,
intN, JSOp)':
jsopcode.cpp:1720: internal compiler error: in set_value_range, at
tree-vrp.c:398
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: [4.4 Regression] ICE in set_value_range, at tree-
                    vrp.c:398
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bero at arklinux dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bero at arklinux dot org]

------- Comment #1 from bero at arklinux dot org  2008-12-18 19:26 -------
Created an attachment (id=16937)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16937&action=view)
gzipped preprocessed source


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2008-12-18 19:45 -------
Works for me as of revision 142793.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2008-12-18 19:48 -------
I don't see any changes between revision 142782 and revision 142793
which may impact this. How is your gcc configured?


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bero at arklinux dot org]

------- Comment #4 from bero at arklinux dot org  2008-12-18 20:08 -------
Sorry, I misread the error message - I saw the warnings about jsparse.cpp, but
the actual ice occurs in jsopcode.cpp


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bero at arklinux dot org]

------- Comment #5 from bero at arklinux dot org  2008-12-18 20:10 -------
Created an attachment (id=16938)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16938&action=view)
gzipped preprocessed source of file actually causing the problem

Attaching correct preprocessed source

# g++ -o test.o -O2 -c jsopcode.ii
jsopcode.cpp: In function 'jsbytecode* Decompile(SprintStack*, jsbytecode*,
intN, JSOp)':
jsopcode.cpp:1720: internal compiler error: in set_value_range, at
tree-vrp.c:398
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16937|0                           |1
        is obsolete|                            |


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-12-18 20:18 -------
Reducing ...


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #7 from hjl dot tools at gmail dot com  2008-12-18 20:20 -------
(In reply to comment #5)
> Created an attachment (id=16938)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16938&action=view) [edit]
> gzipped preprocessed source of file actually causing the problem
> 
> Attaching correct preprocessed source
> 
> # g++ -o test.o -O2 -c jsopcode.ii
> jsopcode.cpp: In function 'jsbytecode* Decompile(SprintStack*, jsbytecode*,
> intN, JSOp)':
> jsopcode.cpp:1720: internal compiler error: in set_value_range, at
> tree-vrp.c:398
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>

It works for me:

[hjl@gnu-9 gcc]$ ./xgcc -B./ /net/gnu-27//export/gnu/import/rrs/jsopcode.ii -O2
-S
./xgcc [hjl@gnu-9 gcc]$ ./xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure
--enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa
--prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local
Thread model: posix
gcc version 4.4.0 20081217 (experimental) [trunk revision 142793] (GCC) 
[hjl@gnu-9 gcc]$ 


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2008-12-18 20:23 -------
(In reply to comment #7)
> gcc version 4.4.0 20081217 (experimental) [trunk revision 142793] (GCC) 

It ICEs for me with gcc version 4.4.0 20081216 (experimental) [trunk revision
142782] (GCC)  on i386-darwin8.11.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2008-12-18 20:24 -------
(In reply to comment #8)
> (In reply to comment #7)
> > gcc version 4.4.0 20081217 (experimental) [trunk revision 142793] (GCC) 
> 
> It ICEs for me with gcc version 4.4.0 20081216 (experimental) [trunk revision
> 142782] (GCC)  on i386-darwin8.11.

Plus there is nothing which touched the tree optimizers in that time.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2008-12-18 23:20 -------
Reduced testcase:
enum JSOp {
  JSOP_GETELEM = 5,
  JSOP_LIMIT
}  ;
typedef struct JSFrameRegs {
  unsigned char *pc;
} JSFrameRegs;
struct JSStackFrame {
  JSFrameRegs *regs;
};
int
f( unsigned char *pc,   enum JSOp nextop )
{
  unsigned char *startpc, *endpc, *pc2, *done;
  enum JSOp op, lastop, saveop;
  while ( pc < endpc    )
  {
    JSStackFrame *fp;
    unsigned format, mode, type;
    if ( ( fp &&  fp->regs &&  pc == fp->regs->pc ) || pc == startpc )
    {
      if (mode == (2U<<5))
        op = (JSOp) ((format & (1U<<8)) ? 256 : 1);
      else
        if (mode == (3U<<5))
          op = (JSOp) ((format & (1U<<8)) ? 257 : 2);
      else
        op = JSOP_GETELEM;
    }
    if (op >= JSOP_LIMIT) {
      if (((format) & 0x001f) != 8)
        return 0;
    }
  }
}


-- CUT ---
This is related to enums as if I change the type of op to int, GCC does not
crash.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-18 23:20:57
               date|                            |
   Target Milestone|---                         |4.4.0


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #10 from hjl dot tools at gmail dot com  2008-12-18 23:20 -------
It is caused by revision 140288:

http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00447.html

If gcc is configured with --enable-checking=assert, you won't see the bug.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2008-12-18 23:21 -------
(In reply to comment #10)
> If gcc is configured with --enable-checking=assert, you won't see the bug.

Well that is called real checking code :).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-checking


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #13 from hjl dot tools at gmail dot com  2008-12-18 23:26 -------
Testcase in comment 11 also fails on Linux/x86-64.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|i686-pc-linux-gnu           |


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2008-12-18 23:28 -------
(In reply to comment #12)
> (In reply to comment #10)
> > If gcc is configured with --enable-checking=assert, you won't see the bug.
> 
> Well that is called real checking code :).
> 

There are

 397       cmp = compare_values (min, max);
 398       gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);

Doesn't --enable-checking=assert turn on gcc_assert?


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2008-12-19 01:19 -------
(In reply to comment #14)
> Doesn't --enable-checking=assert turn on gcc_assert?

Yes but not when that code is wrapped with:
#if defined ENABLE_CHECKING

:)


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[hjl dot tools at gmail dot com]

------- Comment #16 from hjl dot tools at gmail dot com  2008-12-19 01:40 -------
C compiler doesn't crash:

(gdb) f 0
#0  set_value_range (vr=0x15e7bf40, t=VR_RANGE, min=0x2af40ef86fc0, 
    max=0x2af40ef86fc0, equiv=0x0) at ../../src/gcc/tree-vrp.c:398
398           gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
(gdb) call debug_tree (min)
 <integer_cst 0x2af40ef86fc0 type <enumeral_type 0x2af40ef776c0 JSOp> constant
256>
(gdb) call debug_tree (max)
 <integer_cst 0x2af40ef86fc0 type <enumeral_type 0x2af40ef776c0 JSOp> constant
256>
(gdb) p cmp
$4 = 0
(gdb) 

C++ compiler crashes:

(gdb) f 1
#1  0x0000000000c9b2a5 in set_value_range (vr=0x2f069e0, t=VR_RANGE, 
    min=0x2ac27d43b330, max=0x2ac27d429ab0, equiv=0x0)
    at ../../src/gcc/tree-vrp.c:398
398           gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
(gdb) call debug_tree (min)
 <integer_cst 0x2ac27d43b330 type <enumeral_type 0x2ac27d433cc0 JSOp> constant
256>
(gdb) call debug_tree (max)
 <integer_cst 0x2ac27d429ab0 type <enumeral_type 0x2ac27d433cc0 JSOp> constant
7>
(gdb) p cmp
$2 = 1
(gdb) 

Enum looks different in C++.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2008-12-19 01:49 -------
(In reply to comment #16)
> Enum looks different in C++.

Yes they are different because of the way C++ talks about out of range values
and such.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #18 from bonzini at gnu dot org  2008-12-19 06:05 -------
mine.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-12-18 23:20:57         |2008-12-19 06:05:15
               date|                            |


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #19 from bonzini at gnu dot org  2008-12-22 08:52 -------
Smaller testcase, without uninitialized variables too:

enum JSOp
{
  JSOP_GETELEM = 5,
  JSOP_LIMIT
};
extern void g ();
void
f (char *pc, char *endpc, int format, char ***fp, enum JSOp op)
{
  while (pc <= endpc)
    {
      if ((fp && *fp && pc == **fp) || pc == endpc)
        {
          if (format == 1)
            op = (JSOp) 256;
          else if (format == 2)
            op = (JSOp) 257;
          else
            op = JSOP_GETELEM;
        }
      if (op >= JSOP_LIMIT)
        {
          if (format)
            g ();
        }
    }
}


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #20 from bonzini at gnu dot org  2008-12-22 09:05 -------
This is a latent bug in the handling of out-of-bounds values.  It happens
because a value changes from [256, 256] to [256, 257]. VRP then forces the
upper bound to the max-value of the type, generating the invalid range [256,
7].  We should punt and give VARYING.

Probably caused by the tree-ssa-propagate.c hunk of my patch, but also probably
latent.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #21 from bonzini at gnu dot org  2008-12-22 09:30 -------
Created an attachment (id=16961)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16961&action=view)
patch being tested

Testing a patch.


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #23 from bonzini at gnu dot org  2008-12-30 10:38 -------
Fixed.  However, you should check if the code is valid C++ at all, because
out-of-range enum values are handled differently in C and C++ (the bug stemmed
from the fact that op was set to a value that is beyond what the C++ front-end
had set as the maximum value of the enum).


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gcc dot gnu dot org]

------- Comment #22 from bonzini at gnu dot org  2008-12-30 10:38 -------
Subject: Bug 38572

Author: bonzini
Date: Tue Dec 30 10:36:39 2008
New Revision: 142962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142962
Log:
2008-12-30  Paolo Bonzini  <bonzini@gnu.org>

        PR tree-optimization/38572
        * tree-vrp.c (vrp_visit_phi_node): Look out for invalid ranges
        and change them to VARYING.

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


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #24 from bonzini at gnu dot org  2008-12-30 10:39 -------
patch committed -- bug may be latent on 4.3, but there is no known testcase.


-- 

bonzini at gnu dot org changed:

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


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[regehr at cs dot utah dot edu]

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



------- Comment #25 from regehr at cs dot utah dot edu  2009-01-22 05:06 -------
I get this using r143561 on Ubuntu Hardy on x86:

regehr@john-home:~/volatile/tmp126$ current-gcc -O3 -c small.c 
small.c: In function ‘bar’:
small.c:22: internal compiler error: in set_value_range, at tree-vrp.c:398
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

regehr@john-home:~/volatile/tmp126$ cat small.c

long long int foo (long long int si1, int si2)
{
  return 0 && 9223372036854775807LL - si2 || si1 < 0 && si2 < 0
    && si1 < -9223372036854775807LL - 1 - si2 ? : si1;
}

int g_11;
volatile int g_49;

int func_10 (void)
{
  for (g_11 = 1; 1;)
    return 1;
}

int func_25 (void)
{
  int l_28 = 8L;
  return l_28;
}

void bar (int p_9)
{
  int l_146 = 4L;
  func_10 ();
  if (foo
      (p_9,
       ((signed char) (1 - (unsigned int) func_25 () | g_11) / l_146)))
    g_49;
}


-- 


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

[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

------- Comment #26 from bonzini at gnu dot org  2009-01-22 08:08 -------
This is a separate bug. The reduced testcase does not have a single && or || so
it probably existed also before my patch.

It is now bug 38932.


-- 


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