On Linux/Intel64, with revision 131442, I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c -ftree-vectorize -fno-vect-cost-model -msse2 -O2 -fdump-tree-vect-details --param vect-max-version-for-alias-checks=0 -fno-show-column -lm -m32 -o ./no-vfa-pr29145.exe (timeout = 300) PASS: gcc.dg/vect/no-vfa-pr29145.c (test for excess errors) FAIL: gcc.dg/vect/no-vfa-pr29145.c execution test FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 0 loops" 2 FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 1 loops" 1 Revision 131403 is OK.
Revision 131429: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00367.html
Revision 131429 is the cause.
This bug may only happen when you compile for 32bit on 64bit host.
It simply vectorizes all loops in the testcase. It looks like there may be a non-canonical sizetype constant (just wild guesses).
We enter that function with: {4294967288B, +, 4}_1 <polynomial_chrec 0x2acbda7bd500 type <pointer_type 0x2acbd9dd09c0 type <integer_type 0x2acbd9dc1540 int sizes-gimplified public SI size <integer_cst 0x2acbd9db1ab0 constant invariant 32> unit size <integer_cst 0x2acbd9db1720 constant invariant 4> align 32 symtab 0 alias set 2 canonical type 0x2acbd9dc1540 precision 32 min <integer_cst 0x2acbd9db1a20 -2147483648> max <integer_cst 0x2acbd9db1a50 2147483647> pointer_to_this <pointer_type 0x2acbd9dd09c0>> sizes-gimplified public unsigned SI size <integer_cst 0x2acbd9db1ab0 32> unit size <integer_cst 0x2acbd9db1720 4> align 32 symtab 0 alias set -1 canonical type 0x2acbd9dd09c0> arg 0 <integer_cst 0x2acbd9dce510 type <integer_type 0x2acbd9dc1540 int> constant invariant 1> arg 1 <integer_cst 0x2acbda7bf4b0 type <pointer_type 0x2acbd9dd09c0> constant invariant public overflow 4294967288> arg 2 <integer_cst 0x2acbd9db1720 4>> where the HOST_WIDE_INT will be positive (it's not sign-extended). For -m64 we instead get {-8B, +, 4}_1 <polynomial_chrec 0x2b154a2925f0 type <pointer_type 0x2b15498a3b40 type <integer_type 0x2b1549894540 int sizes-gimplified public SI size <integer_cst 0x2b1549884ab0 constant invariant 32> unit size <integer_cst 0x2b1549884720 constant invariant 4> align 32 symtab 0 alias set 2 canonical type 0x2b1549894540 precision 32 min <integer_cst 0x2b1549884a20 -2147483648> max <integer_cst 0x2b1549884a50 2147483647> pointer_to_this <pointer_type 0x2b15498a3b40>> sizes-gimplified public unsigned DI size <integer_cst 0x2b1549884ba0 constant invariant 64> unit size <integer_cst 0x2b1549884bd0 constant invariant 8> align 64 symtab 0 alias set -1 canonical type 0x2b15498a3b40> arg 0 <integer_cst 0x2b15498a1570 type <integer_type 0x2b1549894540 int> constant invariant 1> arg 1 <integer_cst 0x2b154a2948a0 type <pointer_type 0x2b15498a3b40> constant invariant public overflow 18446744073709551608> arg 2 <integer_cst 0x2b1549884720 4>> where the HOST_WIDE_INT will be negative. For consistency you should always use sizetype variables for offsets, as they are properly sign-extended. Using pointer types asks for trouble.
Mine.
Subject: Bug 34769 Author: rguenth Date: Wed Jan 16 16:00:17 2008 New Revision: 131573 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131573 Log: 2008-01-16 Richard Guenther <rguenther@suse.de> PR tree-optimization/34769 * tree-data-ref.c (initialize_matrix_A): Revert fix for PR34458. * tree.c (int_cst_value): Instead make this function more permissive in what it accepts as valid input. Document this function always sign-extends the value. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree.c
Fixed.