User account creation filtered due to spam.

Bug 25203 - [4.0] enable checking failure in g++.dg/opt/mmx2.C
Summary: [4.0] enable checking failure in g++.dg/opt/mmx2.C
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.3
: P1 normal
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-checking, ssemmx
Depends on:
Blocks:
 
Reported: 2005-12-01 13:54 UTC by Kaveh Ghazi
Modified: 2007-02-03 16:05 UTC (History)
1 user (show)

See Also:
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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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