Bug 25203

Summary: [4.0] enable checking failure in g++.dg/opt/mmx2.C
Product: gcc Reporter: Kaveh Ghazi <ghazi>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: gcc-bugs
Priority: P1 Keywords: ice-checking, ssemmx
Version: 4.0.3   
Target Milestone: 4.1.0   
Host: Target: i686-pc-linux-gnu
Build: Known to work: 4.1.0 4.1.1 4.1.2 4.2.0
Known to fail: 4.0.3 Last reconfirmed: 2006-04-07 05:30:26

Description Kaveh Ghazi 2005-12-01 13:54:08 UTC 
On i686-pc-linux-gnu with current gcc-4.0.x, I'm getting a failure in g++.dg/opt/mmx2.C:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01435.html

I think it's triggered by turning on checking, because I don't see other people getting the error.  I configured with: --enable-checking=yes,rtl

I get an ICE here:

Program received signal SIGSEGV, Segmentation fault.
memory_operand (op=0xabababab, mode=VOIDmode) at ../../egcc-4.0-SVN20051130/gcc/recog.c:1279
1279      if (GET_CODE (inner) == SUBREG)

Here the variable "inner" is set to op which is a parameter to the function memory_operand().  And memory_operand() is passed operands[2] from get_attr_memory().  The value is 0xabababab, i.e. uninitialized garbage.

In insn-extract.c, only if checking is enabled, the function insn_extract memsets recog_data.operand ("operands" is a macro for this) to 0xab so that any uninitialized areas get this value.

I don't see this failure with 4.1 or mainline.
Comment 1 Kaveh Ghazi 2005-12-03 20:06:49 UTC 
Here's a reduced testcase, configure 4.0.x with --enable-checking=yes,rtl --target=i686-pc-linux-gnu and compile with:

cc1plus -fpreprocessed mmx2.ii -quiet -dumpbase mmx2.C -mmmx -mtune=pentiumpro -auxbase mmx2 -O2 -version -fmessage-length=0 -o mmx2.s


typedef int __m64 __attribute__ ((__vector_size__ (8)));

static __inline void
_mm_empty (void)
{
  __builtin_ia32_emms ();
}

static __inline __m64
_mm_set_pi32 (int __i1, int __i0)
{
  return (__m64) __builtin_ia32_vec_init_v2si (__i0, __i1);
}

static union u { __m64 m; long long l; } u;
extern "C" void abort (void);

__attribute__((noinline))
void bar (__m64 x)
{
  u.m = x;
}

int
main ()
{
  bar (_mm_set_pi32 (0x000000FF,0xFFFF00FF));
  _mm_empty ();
  if (u.l != 0xffffff00ffLL)
    abort ();
  return 0;
}
Comment 2 Mark Mitchell 2006-01-15 22:51:47 UTC 
I think we should understand this problem, at least, before 4.0.3.
Comment 3 roger 2006-04-07 05:30:26 UTC 
This appears to be a problem with instruction attributes in the x86 backend,
and looks to be still present (but latent?) on mainline.

The problem is that i386.c's "memory" define_attr tries to determine whether
an insn is a "load" for insns of type "mmxadd" if either operands[1]
or operands[2] is a memory operand.  See the (match_operand 2 ...) line,
shortly after line 460 of i386.md.

This interacts badly with the definitions of the *movsi_1 and *movdi_1_rex64
define_insns where certain alternatives claim that they are of insn type
"mmxadd", even though they have only two operands.  This leads the generated
get_attr_memory to inspect the uninitialized operands[2] for these insns.

The problem can be corrected by changing the insn "type" attribute for the
problematic variants of *movsi_1 and *movdi_1_rex64.  Which "type" they should
be (and how that interacts with scheduling etc...) is beyond me.  Perhaps a
new "mmxclr" or "mmxunary" type, or resuse the existing "mmxcvt" type, to
denote unary MMX operations.  Alternatively, the "memory" attribute could be
made more complex to recognize these two exceptions.  Or a third alternative,
is to specify the "memory" attribute of these two insns explicitly.
Comment 4 Gabriel Dos Reis 2007-02-03 16:05:04 UTC 
Fixed in GCC0-4.1.0