This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/69255] ICE (segfault) on x86_64-linux-gnu in "emit_move_insn"


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69255

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#pragma GCC target "avx512vl"
#pragma GCC target "no-avx512vl"
__attribute__ ((__vector_size__ (4 * sizeof (long)))) long long a;
__attribute__ ((__vector_size__ (2 * sizeof (long)))) int b;

void
foo (const long long *p)
{
  a = __builtin_ia32_gather3siv4di (a, p, b, 1, 1);
}

There are several issues.
One is that the error-recovery in ix86_expand_builtin looks wrong, if the call
is to unsupported ISA, then it always returns const0_rtx, which is wrong for
BLKmode.

So I think we want either:
--- i386.c.jj 2016-01-12 14:20:13.000000000 +0100
+++ i386.c 2016-01-13 09:58:57.987193230 +0100
@@ -40249,7 +40249,7 @@ ix86_expand_builtin (tree exp, rtx targe
   error ("%qE needs isa option %s", fndecl, opts);
   free (opts);
 }
-      return const0_rtx;
+      return target ? target : const0_rtx;
     }

   switch (fcode)

or say what rs6000 uses in that case:
      return expand_call (exp, target, ignore);
(though returning target is probably good enough).

The second issue is with expansion of VECTOR_TYPE_P non-automatic VAR_DECLs.
TYPE_MODE for those returns vector_type_mode, so the mode depends on whether
the function's ISA supports those vector modes or not.  But, DECL_RTL of those
VAR_DECLs has been possibly created under different ISA, so there is the
possibility that their DECL_RTL's mode does not match the TYPE_MODE.
Wonder if expansion for VECTOR_TYPE_P (TREE_TYPE (exp)) TREE_STATIC VAR_Ps
should not look at TYPE_MODE of their type and if there is a mismatch, instead
of using DECL_RTL as is, create a different MEM with the mode changed to match.

The question is of course if single element structs with vector type element
don't need similar treatment.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]