http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46805
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2010.12.05 11:07:21
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-05
11:07:21 UTC ---
A non-Go testcase would be nice ...
#1 0x0000000100b3ce41 in supportable_widening_operation (code=NOP_EXPR,
stmt=0x141d3d0a0, vectype_out=0x141d3cdc8, vectype_in=0x141d3cf18,
decl1=0x7fff5fbff1d0, decl2=0x7fff5fbff1c8, code1=0x7fff5fbff238,
code2=0x7fff5fbff234, multi_step_cvt=0x7fff5fbff218,
interm_types=0x7fff5fbff170) at ../../src/trunk/gcc/tree-vect-stmts.c:5521
5521 optab3 = optab_for_tree_code (c1, intermediate_type,
optab_default);
(gdb) p intermediate_type
$1 = (tree) 0x0
for (i = 0; i < 3; i++)
{
intermediate_mode = insn_data[icode1].operand[0].mode;
intermediate_type = lang_hooks.types.type_for_mode
(intermediate_mode,
TYPE_UNSIGNED
(prev_type));
optab3 = optab_for_tree_code (c1, intermediate_type, optab_default);
lang_hooks.types.type_for_mode can return NULL, there is no suitable hook
that will a) return non-NULL always, b) always returns a type for the requested
mode(!)
I doubt a non-Go testcase exists.
Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
middle-end but had a pure middle-end based implementation. A manual
middle-end substitute would be
build_nonstandard_integer_type (GET_MODE_PRECISION (intermediate_mode),
TYPE_UNSIGNED (prev_type));
More uses of type_for_mode exist.
With the vectorizer bits fixed we fall into tree-vect-generic.c which does
577 else
578 /* There is no operation in hardware, so fall back to scalars. */
579 compute_type = TREE_TYPE (type);
where type is already a TImode integer (and TREE_TYPE of it is NULL).
This is because appearantly Go has a DImode integer type but not a SImode
one. Huh. So we have
V2DI = VEC_UNPACK_LO_EXPR <TI>
where the TImode rhs is really V4SI.
The generic vector lowering code is confused by this.
Go -> low priority.
The following vectorizer patch leads to the above failure:
Index: tree-vect-stmts.c
===================================================================
--- tree-vect-stmts.c (revision 167471)
+++ tree-vect-stmts.c (working copy)
@@ -5516,7 +5516,7 @@
for (i = 0; i < 3; i++)
{
intermediate_mode = insn_data[icode1].operand[0].mode;
- intermediate_type = lang_hooks.types.type_for_mode
(intermediate_mode,
+ intermediate_type = build_nonstandard_integer_type
(GET_MODE_PRECISION (intermediate_mode),
TYPE_UNSIGNED
(prev_type));
optab3 = optab_for_tree_code (c1, intermediate_type, optab_default);
optab4 = optab_for_tree_code (c2, intermediate_type, optab_default);
@@ -5637,7 +5637,7 @@
for (i = 0; i < 3; i++)
{
intermediate_mode = insn_data[icode1].operand[0].mode;
- intermediate_type = lang_hooks.types.type_for_mode
(intermediate_mode,
+ intermediate_type = build_nonstandard_integer_type
(GET_MODE_PRECISION (intermediate_mode),
TYPE_UNSIGNED
(prev_type));
interm_optab = optab_for_tree_code (c1, intermediate_type,
optab_default);
another fix would be to catch intermediate_type == NULL here and fail
vectorization (but using the langhook is wrong here anyways).
Confirmed at least.
