[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2007-04-25 Thread rguenth at gcc dot gnu dot org
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-25 17:10 --- Subject: Bug 29446 Author: rguenth Date: Wed Apr 25 17:10:31 2007 New Revision: 124158 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124158 Log: 2007-04-25 Richard Guenther <[EMAIL PROTECTED]>

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread rguenth at gcc dot gnu dot org
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-13 20:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread rguenth at gcc dot gnu dot org
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-13 20:09 --- Subject: Bug 29446 Author: rguenth Date: Fri Oct 13 20:09:10 2006 New Revision: 117705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117705 Log: 2006-10-13 Richard Guenther <[EMAIL PROTECTED]> PR

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread patchapp at dberlin dot org
--- Comment #7 from patchapp at dberlin dot org 2006-10-13 12:45 --- Subject: Bug number PR29446 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00698.html -- http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread rguenth at gcc dot gnu dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-13 10:38 --- I have a patch to get rid of that beast completely. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread rguenth at gcc dot gnu dot org
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-13 10:07 --- It looks like we would need to recurse down into symbolic ranges in fix_equivalence_set, which would be far too costly. So a conservative fix for 4.2 is to just not record symbolic equivalencies at all. I wonder if

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread rguenth at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-13 09:18 --- We end up comparing (GT_EXPR) i_92 with ubound1_111 which have the following value ranges and equivalences: i_92: [1, 3] EQUIVALENCES: { i_1 j_2 i_67 j_70 } (4 elements) i_1: ~[0, 0] EQUIVALENCES: { } (0 elements

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-13 Thread rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-13 08:22 --- Slightly less undefined, ICEs with -O -ftree-vrp -funswitch-loops: void f(_Bool D917, int j0, int ubound1, int ubound5) { int i, j = j0; int (*abc)[3]; i = 1; while (1) { if (j <= 3) whil

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-12 Thread pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-13 03:34 --- here is a shorter testcase: void f(void) { int i, ubound1, j, ubound5; int (*abc)[3]; i = 1; while (1) { if (j <= 3) while (1) { _Bool D917; if (i !=

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

2006-10-12 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-13 03:19 --- C testcase: void f(int *n, int *m) { int i; int ubound0; int ubound1; int stride2; int offset3; int size4; int j; int ubound5; int size6; int D919; __SIZE_TYPE__ D920; int D921; unsigned int