public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "roger at eyesopen dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/25203] [4.0] enable checking failure in g++.dg/opt/mmx2.C
Date: Fri, 07 Apr 2006 05:30:00 -0000	[thread overview]
Message-ID: <20060407053027.13885.qmail@sourceware.org> (raw)
In-Reply-To: <bug-25203-578@http.gcc.gnu.org/bugzilla/>



------- 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


  parent reply	other threads:[~2006-04-07  5:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-01 13:54 [Bug c++/25203] New: " ghazi at gcc dot gnu dot org
2005-12-01 13:57 ` [Bug c++/25203] " ghazi at gcc dot gnu dot org
2005-12-03 20:06 ` [Bug target/25203] " ghazi at gcc dot gnu dot org
2006-01-15 22:51 ` mmitchel at gcc dot gnu dot org
2006-03-11  3:17 ` mmitchel at gcc dot gnu dot org
2006-04-07  5:30 ` roger at eyesopen dot com [this message]
2007-02-03 16:05 ` gdr at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060407053027.13885.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).