https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68091
Bug ID: 68091
Summary: [6 Regression] [SH] internal compiler error: in
expand_vec_cond_expr, at optabs.c:5391
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kkojima at gcc dot gnu.org
Target Milestone: ---
Target: sh4*-*-*
The recent change of middle-end for vector operations causes some new
ICEs in the testsuite on sh4. A Typical one is:
trunk/gcc/testsuite/g++.dg/ext/vector27.C:12:16: internal compiler error: in
expand_vec_cond_expr, at optabs.c:5391
0x877369f expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../ORIG/trunk/gcc/optabs.c:5390
0x8588a0e do_store_flag
../../ORIG/trunk/gcc/expr.c:11052
0x8588a0e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../ORIG/trunk/gcc/expr.c:9010
0x846bb89 expand_gimple_stmt_1
../../ORIG/trunk/gcc/cfgexpand.c:3617
It seems that the middle-end change reveals a target problem that
sh_vector_mode_supported_p returns true even the target has no mov
insns for some vector modes.
bool
sh_vector_mode_supported_p (machine_mode mode)
{
if (TARGET_FPU_ANY
&& ((mode == V2SFmode)
|| (mode == V4SFmode)
|| (mode == V16SFmode)))
return true;
...
It looks that this TARGET_FPU_ANY should be TARGET_SHMEDIA_FPU in
the first place, because all movv* patterns in sh.md are written for
SHMEDIA only. The ICEs seen only on sh4 went away with replacing
TARGET_FPU_ANY with TARGET_SHMEDIA_FPU in sh_vector_mode_supported_p.
Although I know that we shouldn't add the new sh5 hunks, I think
that this change is rather a preparation to zap them out.
