$ cat a.c void foo(void) { static int irows[50000]; int i; for (i = 1; i < 1000; i++) irows[i-1] = i; } $ gcc -c -O1 -march=athlon-xp -ftree-vectorize a.c a.c: In function ‘foo’: a.c:8: internal compiler error: in expand_simple_binop, at optabs.c:1192 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. $ gcc -v Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070209 --enable-languages=c,fortran --host=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20070209 (experimental) The original bug report (http://gcc.gnu.org/ml/fortran/2007-02/msg00288.html) was about the follow Fortran code: subroutine gaussj2_cvb(n) dimension irows(n) do 100 i=1,n 100 irows(i)=i end When someone fixes this, can you verify that the ICE is also gone on the Fortran code (same optimization options)?
This works fine with me on powerpc-darwin with -O1 -ftree-vectorize -maltivec plus the loop was vectorized also.
I get ./cc1 -quiet -O -march=athlon-xp -m32 -ftree-vectorize x.i x.i: In function 'foo': x.i:2: error: invalid reference prefix {4, 4, 4, 4} x.i:2: error: invalid reference prefix {4, 4, 4, 4} x.i:2: error: invalid reference prefix {4, 4, 4, 4} x.i:2: error: invalid reference prefix {4, 4, 4, 4} x.i:2: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. After vectorization: <bb 2>: stmp_var_.29_22 = 2; stmp_var_.30_23 = stmp_var_.29_22 + 1; stmp_var_.31_24 = stmp_var_.30_23 + 1; vect_cst_.32_25 = {1, stmp_var_.29_22, stmp_var_.30_23, stmp_var_.31_24}; vect_cst_.33_26 = {4, 4, 4, 4}; vect_pirows.39_29 = (vector int *) &irows; vect_pirows.35_30 = vect_pirows.39_29; # ivtmp.41_33 = PHI <ivtmp.41_34(7), 0(2)> # ivtmp.40_31 = PHI <ivtmp.40_32(7), vect_pirows.35_30(2)> # vect_vec_iv_.34_27 = PHI <vect_vec_iv_.34_28(7), vect_cst_.32_25(2)> # ivtmp.25_1 = PHI <ivtmp.25_5(7), 999(2)> # i_10 = PHI <i_4(7), 1(2)> <L0>:; D.1842_3 = i_10 + -1; vect_vec_iv_.34_28 = vect_vec_iv_.34_27 + vect_cst_.33_26; *ivtmp.40_31 = vect_vec_iv_.34_27; i_4 = i_10 + 1; ivtmp.25_5 = ivtmp.25_1 - 1; ivtmp.40_32 = ivtmp.40_31 + 16B; ivtmp.41_34 = ivtmp.41_33 + 1; if (ivtmp.41_34 < 249) goto <L5>; else goto <L10>; (looks good) but then veclower does # ivtmp.41_33 = PHI <ivtmp.41_34(7), 0(2)> # ivtmp.40_31 = PHI <ivtmp.40_32(7), vect_pirows.35_30(2)> # vect_vec_iv_.34_27 = PHI <vect_vec_iv_.34_28(7), vect_cst_.32_25(2)> # ivtmp.25_1 = PHI <ivtmp.25_5(7), 999(2)> # i_10 = PHI <i_4(7), 1(2)> <L0>:; D.1842_3 = i_10 + -1; D.1899_20 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 0>; D.1900_19 = BIT_FIELD_REF <vect_cst_.33_26, 32, 0>; D.1901_17 = D.1899_20 + D.1900_19; D.1902_35 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 32>; D.1903_36 = BIT_FIELD_REF <vect_cst_.33_26, 32, 32>; D.1904_37 = D.1902_35 + D.1903_36; D.1905_38 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 64>; D.1906_39 = BIT_FIELD_REF <vect_cst_.33_26, 32, 64>; D.1907_40 = D.1905_38 + D.1906_39; D.1908_41 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 96>; D.1909_42 = BIT_FIELD_REF <vect_cst_.33_26, 32, 96>; D.1910_43 = D.1908_41 + D.1909_42; vect_vec_iv_.34_28 = {D.1901_17, D.1904_37, D.1907_40, D.1910_43}; *ivtmp.40_31 = vect_vec_iv_.34_27; i_4 = i_10 + 1; ivtmp.25_5 = ivtmp.25_1 - 1; ivtmp.40_32 = ivtmp.40_31 + 16B; ivtmp.41_34 = ivtmp.41_33 + 1; if (ivtmp.41_34 < 249) goto <L5>; else goto <L10>; but then DOM const-props into the BIT_FIELD_REFs which confuses us: # ivtmp.44_8 = PHI <ivtmp.44_45(3), 0(2)> # vect_vec_iv_.34_27 = PHI <vect_vec_iv_.34_28(3), vect_cst_.32_25(2)> <L0>:; D.1899_20 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 0>; D.1900_19 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 0>; D.1901_17 = D.1899_20 + D.1900_19; D.1902_35 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 32>; D.1903_36 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 32>; D.1904_37 = D.1902_35 + D.1903_36; D.1905_38 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 64>; D.1906_39 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 64>; D.1907_40 = D.1905_38 + D.1906_39; D.1908_41 = BIT_FIELD_REF <vect_vec_iv_.34_27, 32, 96>; D.1909_42 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 96>; D.1910_43 = D.1908_41 + D.1909_42; vect_vec_iv_.34_28 = {D.1901_17, D.1904_37, D.1907_40, D.1910_43}; MEM[symbol: irows, index: ivtmp.44_8] = vect_vec_iv_.34_27; ivtmp.44_45 = ivtmp.44_8 + 16; if (ivtmp.44_45 != 3984) goto <L0>; else goto <L15>; so we fail to fold BIT_FIELD_REF <{4, 4, 4, 4}, 32, 96> to a constant for example.
(In reply to comment #2) > ./cc1 -quiet -O -march=athlon-xp -m32 -ftree-vectorize x.i > x.i: In function 'foo': > x.i:2: error: invalid reference prefix > {4, 4, 4, 4} > > x.i:2: error: invalid reference prefix > {4, 4, 4, 4} > > x.i:2: error: invalid reference prefix > {4, 4, 4, 4} > > x.i:2: error: invalid reference prefix > {4, 4, 4, 4} > > x.i:2: internal compiler error: verify_stmts failed It's still present on trunk, and it's a regression from the 4.2 branch.
I also saw this on powerpc64, on a different testcase (vectorizing longs with -m64). seems like constant propagation during dom3 propagates the vector initializer into a BIT_FIELD_EXPR, which results in invalid gimple?
this is the testcase I have ICE-ing on powerpc64-yellowdog, when compiled with -ftree-vectorize -maltivec -m64 -O2: long stack_vars_sorted[32]; void partition_stack_vars (long stack_vars_num) { long si, n = stack_vars_num; for (si = 0; si < n; ++si) stack_vars_sorted[si] = si; } (extracted from cfgexpand.c which ICEs during bootstrap with vectorization)
I think this was introduced by me, by making vector based CONSTRUCTOR with CONSTANT set invariant.
patch: http://gcc.gnu.org/ml/gcc/2007-03/msg00918.html
Subject: Bug number PR30784 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/2007-03/msg01607.html
Subject: Bug 30784 Author: dorit Date: Sun Mar 25 12:08:29 2007 New Revision: 123197 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123197 Log: PR tree-optimization/30784 * fold-const.c (fold_ternary): Handle CONSTRUCTOR in case BIT_FIELD_REF. Added: trunk/gcc/testsuite/gcc.dg/vect/pr30784.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
Fixed.
*** Bug 30958 has been marked as a duplicate of this bug. ***