Re: [PATCH] use build_vector_from_val in more places

[Uros Bizjak <ubizjak at gmail dot com>]

Hello!

> The recently-introduced build_vector_from_val function can be used in
> several places, centralizing TREE_LIST use and making it easier to
> remove at a later point.  The assertion change in build_vector_from_val
> is needed so as to not ICE while building libgfortran and is, I think,
> more correct in any event.
>
> Tested on x86_64-unknown-linux-gnu.  OK to commit?
>
> -Nathan
>
> 	* fold-const.c (build_zero_vector): Use build_vector_from_val.
> 	* tree-vect-loop.c (get_initial_def_for_induction): Likewise.
> 	(get_initial_def_for_reduction): Likewise.
> 	* tree-vect-slp.c (vect_get_constant_vectors): Likewise.
> 	* tree-vect-stmts.c (vect_get_vec_def_for_operand): Likewise.
> 	* tree.c (build_one_cst): Likewise.
> 	(build_vector_from_val): Use types_compatible_p for assert.

This patch caused a regression on x86_64-pc-linux-gnu [1]:

FAIL: gcc.dg/torture/pr45720.c  -O2 -flto  (internal compiler error)
FAIL: gcc.dg/torture/pr45720.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/pr45720.c  -O2 -fwhopr  (internal compiler error)
FAIL: gcc.dg/torture/pr45720.c  -O2 -fwhopr  (test for excess errors)

You can trigger this ICE using following command sequence:

$ <path>/gcc/xgcc -B <path>/gcc -O2 -flto -ftree-vectorize -c pr45720.c
$ <path>/gcc/lto1 -O2 -ftree-vectorize -quiet pr45720.o

In file included from :0:0:
pr45720.c: In function ‘foobar’:
pr45720.c:28:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Backtrace:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000008e2adf in build_vector_from_val (vectype=<value
optimized out>, sc=0x7ffff1f26ce0)
    at ../../gcc-svn/trunk/gcc/tree.c:1379
#2  0x00000000008a2a33 in vect_get_vec_def_for_operand
(op=0x7ffff1f26ce0, stmt=0x7ffff1f32aa8, scalar_def=0x0)
    at ../../gcc-svn/trunk/gcc/tree-vect-stmts.c:1034
#3  0x00000000008a2cce in vect_get_vec_defs (op0=<value optimized
out>, op1=0x7ffff1f26ce0, stmt=0x7ffff1f32aa8,
    vec_oprnds0=<value optimized out>, vec_oprnds1=<value optimized
out>, slp_node=<value optimized out>)
    at ../../gcc-svn/trunk/gcc/tree-vect-stmts.c:1232
#4  0x00000000008a6e9f in vectorizable_operation (stmt=0x7ffff1f32aa8,
gsi=0x7fffffffdc70,
    vec_stmt=<value optimized out>, slp_node=0x0) at
../../gcc-svn/trunk/gcc/tree-vect-stmts.c:2593
#5  0x00000000008ab6c3 in vect_transform_stmt (stmt=0x7ffff1f32aa8,
gsi=0x7fffffffdc70,
    strided_store=0x7fffffffdcaf "", slp_node=0x0,
slp_node_instance=<value optimized out>)
    at ../../gcc-svn/trunk/gcc/tree-vect-stmts.c:4764

So, it is caused by the change in vect_get_vec_def_for_operand.

[1]: http://gcc.gnu.org/ml/gcc-regression/2010-10/msg00310.html

Uros.