Hi,
This seems to have caused PR58373. The bug occurs where GEN_INT would
previously have then been used to build a constant of vector mode.
These pop in a few places when building for AArch64, though I did
the debugging using gcc.target/aarch64/vect-fcm-eq-d.c
Here we could get in to the situation where
simplify_unary_expression_1 would see (V2DI: NOT (NEG X))
and try to generate (V2DI: PLUS (X - 1)). In turn, we would reach the
call in plus_constant to gen_int_mode (-1, v2di), followed by
trunc_int_for_mode (-1, v2di) and this assert would trigger:
/* You want to truncate to a _what_? */
gcc_assert (SCALAR_INT_MODE_P (mode));
In this fix I catch the case where gen_int_mode has been asked to
build a vector mode, and call trunc_int_for_mode on the inner mode
of that vector. A similar fix could sit in trunc_int_for_mode if
you would prefer.
Bootstrapped on x86_64-unknown-linux-gnu with no issues and regression
tested for aarch64-none-elf with the expected benefits and no regressions.
Thanks,
James
---
gcc/
2013-09-10 James Greenhalgh <[email protected]>
PR rtl-optimization/58383
* emit-rtl.c (gen_int_mode): Handle vector modes.
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 8a7b8a5..cf26bf1 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -417,7 +417,13 @@ gen_rtx_CONST_INT (enum machine_mode mode ATTRIBUTE_UNUSED, HOST_WIDE_INT arg)
rtx
gen_int_mode (HOST_WIDE_INT c, enum machine_mode mode)
{
- return GEN_INT (trunc_int_for_mode (c, mode));
+ HOST_WIDE_INT c1;
+ if (SCALAR_INT_MODE_P (mode))
+ c1 = trunc_int_for_mode (c, mode);
+ else
+ c1 = trunc_int_for_mode (c, GET_MODE_INNER (mode));
+
+ return GEN_INT (c1);
}
/* CONST_DOUBLEs might be created from pairs of integers, or from
