FreePOOMA 2.4.1 fails to build on powerpc-linux with beginning with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=114057 r114057 | rakdver | 2006-05-24 22:55:15 +0000 (Wed, 24 May 2006) Output with a minimized testcase: elm3b145% /opt/gcc-nightly/trunk/bin/g++ -c -O2 poomabug.cc poomabug.cc: In constructor ‘GLD<Dim>::GLD(const II<Dim>&, const PP&, const CM<Dim>&) [with PP = GP<2> ()(), int Dim = 2]’: poomabug.cc:117: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in adjust_range_with_scev, at tree-vrp.c:2079 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 11574 [details] minimized testcase
Confirmed. Shorter testcase (fails with C or C++ frontend): ============================================= static int* foo(int *q, int j) { return q + j; } int* r; void bar(int *p) { int i; for (i=0; i<2; ++i) r = i ? foo(p,i-1) : 0; } =============================================
Here is a testcase without inline functions: void bar(int *p, int t1) { int i; static int *tt; for (i=0; i<2; ++i) if (i) { int t = i - 1; tt = p+t; } }
The code to do: 2098 /* If we just created an invalid range with the minimum 2099 greater than the maximum, take the maximum all the 2100 way to +INF. */ 2101 if (compare_values (min, max) == 1) 2102 max = TYPE_MAX_VALUE (TREE_TYPE (max)); Was added by: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110261
Someone who understands SCEV really needs to fix it. It's been a consistent source of problems for VRP -- whether it's giving us bogus ranges (ranges outside the given type) or claiming variables do not wrap when in fact they do wrap (IIRC there's still an outstanding PR due to this problem). If someone were to fix the SCEV problem touched by pr 25900, then the offending VRP code could be eliminated. Jeff
Subject: Re: [4.2 Regression] tree check failure building FreePOOMA > Someone who understands SCEV really needs to fix it. On this particular piece of code SCEV seems to behave just fine; you ask for the evolution of a pointer, and then use TYPE_MAX_VALUE on its type -- that's not going to work. > It's been a consistent > source of problems for VRP -- whether it's giving us bogus ranges (ranges > outside the given type) or claiming variables do not wrap when in fact they do > wrap (IIRC there's still an outstanding PR due to this problem). > > If someone were to fix the SCEV problem touched by pr 25900, then the offending > VRP code could be eliminated. I will have a look.
After a closer investigation, there indeed seems to be a problem in chrec_convert, I am preparing a patch. Nevertheless, the code in VRP still needs fixing -- the problem might still be reproduced even with a completely correct scev, when part of the compiled code is unreachable (and we are not able to determine this in compile time), or for invalid programs.
Subject: Bug 27865 Author: rakdver Date: Thu Aug 17 08:22:05 2006 New Revision: 116213 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116213 Log: PR tree-optimization/27865 * tree-vrp.c (adjust_range_with_scev): Do not use TYPE_{MIN,MAX}_VALUE for pointer types. * tree-scalar-evolution.c (fold_used_pointer_cast, pointer_offset_p, fold_used_pointer, pointer_used_p): New functions. (analyze_scalar_evolution_1): Use fold_used_pointer. * tree-chrec.c (convert_affine_scev): Convert no-op casts correctly. * tree-ssa-loop-ivopts.c (generic_type_for): Return integral type for pointers. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-vrp.c
Subject: Bug 27865 Author: hubicka Date: Thu Aug 17 09:44:12 2006 New Revision: 116220 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116220 Log: PR tree-optimization/27865 * reload1.c (forget_marked_reloads): New function. (forget_old_reloads_1): When data are passed, just mark the registers for later removal. (reload_as_needed): Use the new mechanizm. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c
Fixed.