/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v test.c -dumpbase test.c -msse2 -auxbase-strip test.o -O -version -ftree-vectorize -o test.o GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051007 (experimental). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129306 Compiler executable checksum: a278381769db4d67bad1ec630ceb45dd test.c: In function 'test': test.c:4: error: definition in block 1 does not dominate use in block 0 for SSA_NAME: D.1603_5 in statement: base_off.27_12 = D.1603_5 * 16; test.c:4: internal compiler error: verify_ssa failed Configured with: ../gcc/configure --prefix=/tmp/gcc41 --enable-languages=c --disable-nls --enable-checking=assert,rtlflag,misc ======================================================== void dSetZero (double *a); void test() { double A[12]; int i; dSetZero (A); for (i=0; i<6; i++) A[i+2*(i/2)] = 4; dSetZero (A); } ========================================================
Confirmed, this was always broken in that we got wrong code in 4.0.0 but now we get an ICE which means this is a regression and a progression. Adding -W -Wall for 4.0, you get a warning: t.c: In function ‘test’: t.c:9: warning: ‘({anonymous})’ is used uninitialized in this function
There are two problems here: 1) This is the data-reference structure created (using the same testcase but with floats instead of doubles): Created dr for A[D.1705_7] base_address: &A offset from base address: (<unnamed type>) (D.1703_5 * 8) constant offset from base address: 0 base_object: A step: 4B misalignment from base: memtag: A We then use the information in the fields above to calculate the first address accessed, as follows: base_off.31_18 = D.1703_5 * 8; vect_pA.32_19 = &A + base_off.31_18; but the problem is that we can't use the expression "D.1703_5 * 8" from field "offset from base address" as is, because D.1703_5 depends on other computations that should take place first. I think we had this problem in the past but it had been solved. I wonder why it reappeared - maybe this is related to the second problem: 2) This loop shouldn't be vectorized in the first place, because the vectorizer can currently handle only consecutive accesses, but this loop accesses locations {0,1,4,5,8,9}. For some reason (scalar evolution bug? dataref analysis bug?) we conclude that the step of the access is simply 4B (i.e. consecutive accesses). (Indeed for doubles, pairs of iterations can be vectorized ({0,1} {4,5} and {8,9}) with a proper stride between the vectorized iterations, but the vectorizer can't do something like that now).
I think, it's the same bug in scev that my autovect patch http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00252.html solved (and Sebastian reverted it). Here scev analyzer calculates the evolution of 'D.1703_5 * 2 + i_15', where 'D.1703_5 = i_15/2'. Scev doesn't handle division, therefore for D.1703_5 we get unknown scev, but then it's combined with the rest of the expression, erroneously leading to {D.1703_5*2, +, 1}. Ira
Subject: Re: [4.1 Regression] ICE: verify_ssa failed with -O -msse2 -ftree-vectorize irar at il dot ibm dot com wrote: > Here scev analyzer calculates the evolution of 'D.1703_5 * 2 + i_15', > where 'D.1703_5 = i_15/2'. Scev doesn't handle division, therefore > for D.1703_5 we get unknown scev, but then it's combined with the > rest of the expression, erroneously leading to {D.1703_5*2, +, 1}. > I don't follow: "unknown + something" should be folded into "unknown", not {D.1703_5*2, +, 1}_x: if D.1703_5 is defined in loop_x, it potentially has an evolution in loop_x. I'm thinking that a test: if (!expr_invariant_in_loop_p (loop, CHREC_LEFT (chrec))) then give up with this case, would solve this bug.
Subject: Re: [4.1 Regression] ICE: verify_ssa failed with -O -msse2 -ftree-vectorize Sebastian Pop wrote: > > if (!expr_invariant_in_loop_p (loop, CHREC_LEFT (chrec))) > then give up with this case, > > would solve this bug. We already do this! By the way, why do we need the "init == expr" check? The following (not tested yet) patch solves this bug. Anybody remembers about why we have the extra check? *** tree-data-ref.c.~2.44.~ 2005-09-24 21:12:03.000000000 +0200 --- tree-data-ref.c 2005-10-12 18:54:38.000000000 +0200 *************** *** 1124,1130 **** return false; init = initial_condition_in_loop_num (access_fn, loop->num); ! if (init == expr && !expr_invariant_in_loop_p (loop, init)) /* Not enough information: may be not loop invariant. E.g., for a[b[i]], we get a[D], where D=b[i]. EXPR is D, its initial_condition is D, but it depends on i - loop's induction --- 1124,1130 ---- return false; init = initial_condition_in_loop_num (access_fn, loop->num); ! if (!expr_invariant_in_loop_p (loop, init)) /* Not enough information: may be not loop invariant. E.g., for a[b[i]], we get a[D], where D=b[i]. EXPR is D, its initial_condition is D, but it depends on i - loop's induction
Subject: Bug 24262 CVSROOT: /cvs/gcc Module name: gcc Changes by: spop@gcc.gnu.org 2005-10-13 11:52:58 Modified files: gcc : ChangeLog tree-data-ref.c Log message: PR tree-optimization/24262 * tree-data-ref.c (analyze_offset_expr): Check that init is invariant in loop all the time. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10152&r2=2.10153 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.c.diff?cvsroot=gcc&r1=2.44&r2=2.45
Fixed.
Subject: Bug 24262 Author: irar Date: Mon Oct 24 09:38:20 2005 New Revision: 105376 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105376 Log: Bring over from mainline: 2005-10-12 Sebastian Pop <pop@cri.ensmp.fr> PR tree-optimization/24262 * tree-data-ref.c (analyze_offset_expr): Check that init is invariant in loop all the time. Modified: branches/autovect-branch/gcc/ChangeLog.autovect branches/autovect-branch/gcc/tree-data-ref.c