https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65877
Bug ID: 65877
Summary: ICE: various internal errors with attribute(target)
when mixing generic and non-generic vectors
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.suchanek at imgtec dot com
I came across some ICEs whilst implementing target attribute for MIPS and it
appears to be more generic. At least the following test case (with target
attribute adapted for x86) fails in the same place:
/* Excerpt from emmintrin.h */
#pragma GCC push_options
#pragma GCC target("sse2")
typedef char __v16qi __attribute__ ((__vector_size (16)))
#pragma GCC pop_options
__v16qi a, b, c;
__attribute__((target("sse2")))
__v16qi foo()
{
return a;
}
gcc -O1 -msse -mno-sse2 fails with error (reproducible on the trunk and likely
in older releases):
t-x86.c: In function`foo`:
t-x86.c:41:10: internal compiler error: in emit_move_insn, at expr.c:3601
return b;
^
0x9a754d emit_move_insn(rtx_def*, rtx_def*)
/scratch/mips-gcc/src/gcc/gcc/expr.c:3600
0x87b031 expand_value_return
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3177
0x87b851 expand_return
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3300
0x87ba89 expand_gimple_stmt_1
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3373
0x87bff2 expand_gimple_stmt
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3497
0x8830c2 expand_gimple_basic_block
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:5509
0x884d39 execute
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions
It doesn't crash when I do an assignment in the function e.g. a = b; since
during expansion convert_move is called that appears to fix up the modes but it
does not seem to work for a simple addition i.e. a = b + c, and throws a
different internal error.
The test cases for the target attribute avoid using a global variable and I've
seen only an example of using an array of vectors that doesn't expose this.
Wrapping declarations of variables with #pragma GCC push_options/pop_options
and adding #pragma GCC target forces to use vector modes as if it was compiled
with -msse2 and no error is thrown.
One of the problems I see is that TYPE_MODE(TREE_TYPE(a)) has V16QImode but the
DECL_MODE(a) has TImode because during layout the current target did not have
SSE2. This is pretty much the same analysis as Jakub's
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00708.html but it relates to AVX.
I imagine __m256 failing for target("avx") too having BLKmode instead of
TImode.
__v4si works for target("sse2") as ix86_vector_mode_supported_p returns true
since SSE supports V4SImode but I'm almost confident that all SSE2 supported
modes would crash.
There are other failing cases with the one already mentioned above:
__attribute__((target("sse2")))
__void foo2()
{
a = b + c;
}
__attribute__((target("sse2")))
__v16qi foo3(__v16qi x)
{
return x;
}
ICEing differently.
Or maybe I missed something obvious and vectors shouldn't be used like that?
Mixing generic and non-generic vectors does not seem to be a good idea but I
think ICEs are still bad and this would need either fixing or some diagnostics.
