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 <james.greenha...@arm.com> 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