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

2009-01-22 Thread 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

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

2009-01-21 Thread regehr at cs dot utah dot edu 


--- 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:

reg...@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  for instructions.

reg...@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

2008-12-30 Thread 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

2008-12-30 Thread 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

2008-12-30 Thread 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  

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

2008-12-22 Thread 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

2008-12-22 Thread 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

2008-12-22 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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)
  constant
256>
(gdb) call debug_tree (max)
  constant
256>
(gdb) p cmp
$4 = 0
(gdb) 

C++ compiler crashes:

(gdb) f 1
#1  0x00c9b2a5 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)
  constant
256>
(gdb) call debug_tree (max)
  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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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|-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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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  for instructions.
>

It works for me:

[...@gnu-9 gcc]$ ./xgcc -B./ /net/gnu-27//export/gnu/import/rrs/jsopcode.ii -O2
-S
./xgcc [...@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) 
[...@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

2008-12-18 Thread 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

2008-12-18 Thread 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  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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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

2008-12-18 Thread 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