------- Comment #3 from roger at eyesopen dot com 2006-04-07 05:30 -------
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.
--
roger at eyesopen dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2006-04-07 05:30:26
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25203
