Red Hat Bugzilla – Bug 171689
Crash using 8-byte integral vector data types
Last modified: 2007-11-30 17:11:16 EST
From Bugzilla Helper: User-Agent: Opera/8.50 (Windows NT 5.1; U; en) Description of problem: gcc -msse2 gcc_vector_bug.c MPI_Op_vect.c: In function ?MPI_op_vector_uquad_prod?: MPI_Op_vect.c:95: error: unrecognizable insn: (insn 53 51 54 3 (set (reg:DI 60 [ D.1581 ]) (vec_select:DI (reg:V2DI 90 [ D.1551 ]) (parallel [ (const_int 1 [0x1]) ]))) -1 (nil) (expr_list:REG_DEAD (reg:V2DI 90 [ D.1551 ]) (nil))) MPI_Op_vect.c:95: internal compiler error: in extract_insn, at recog.c:2020 Version-Release number of selected component (if applicable): gcc-4.0.1-4.fc4 How reproducible: Always Steps to Reproduce: 1.gcc -msse2 gcc_vector_bug.c 2. 3. Actual Results: internal compiler error Expected Results: Beatiful, fast code ;-) Additional info: Snip from info gcc: "All the basic integer types can be used as base types, both as signed and as unsigned: `char', `short', `int', `long', `long long'. In addition, `float' and `double' can be used to build floating-point vector types." Hence, I expect signed/unsigned long long to work, although I understand it will not generate any sse instructions.
Created attachment 120454 [details] Preprocessed C source
Created attachment 122369 [details] Reduced testcase This is a reduced testcase that triggers the same bug in GCC 4.0, but no in GCC mainline. The error is gone not because the bug was fixed, but rather because GCC now selects alternate instructions to perform the multiply, in such a way that extracting the second member of a V2DI vector is no longer necessary.
Created attachment 122370 [details] Patch that fixes the bug The problem is that sse.md does not support vec_select of a V2DI extracting the second element, but the modified function emits that anyway. I don't know much about vector capabilities in x86, but I'd expect there to be a better way to extract the second member of the array. Having no clue of what it is, I thought I'd just make sure we don't emit the incorrect pattern.
Pay no attention to the `gcc34' in the patch filename. It was meant to be gcc4, sorry.
Created attachment 126880 [details] Combined backport of patches that got accepted upstream to fix this bug A somewhat more involved fix went in upstream to make sure this bug and similar ones would not resurface. The attached patch is a backport from the following 3 patches that hit upstream, that I created shortly after the last one was accepted, but that I failed to update here. I had a note in my to-do list to do so, but it kept being pushed back :-( http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00386.html http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00481.html http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01636.html
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
Fixed in gcc-4.1.0-10 and above in rawhide and gcc-4.1.0-15.fc5 in FC5.