public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Hans-Peter Nilsson <hp@bitrange.com>
To: gcc-patches@gcc.gnu.org
Subject: Committed: fix PR49285, breakage building libgcc2 for MMIX
Date: Mon, 06 Jun 2011 04:10:00 -0000	[thread overview]
Message-ID: <alpine.BSF.2.00.1106060006270.49583@dair.pair.com> (raw)

I needed a baseline for PR48542 (problems with setjmp/longjmp), but
building MMIX was broken on trunk.  It was "bitten" by the fixups to
predicate matching done recentlish.  The comment above the MMIX
truncdfsf2 expander complains about having to use an expander to
force an operand to memory - and then goes on and uses memory_operand
for that operand anyway!  That accidentally worked before the fixup,
because after copying the failing operand to a new pseudo, the
expander was called without the optabs machinery doublechecking the
new pseudo against the predicate.  While I stand by the comment and
still think the optabs machinery could automatically fix up operands
as needed to force an operand into memory when the predicate says so,
it hasn't worked like that before, and I guess it's no use adding
something like that just for one port, where an expander will do.

Committed after building and regtesting for MMIX, where the build
failed in libgcc2.c.  FWIW, there's a whopping 252 regressions on the
4.6-branch and 256 on trunk (after this patch) according to Geoff's
test-script compared to gcc-4.5 era, with "just" 1..6 regressions for
the 4.3, 4.4 and 4.5 branches.  Ouch.

gcc:

	PR target/49285
	* config/mmix/mmix.md ("truncdfsf2", "extendsfdf2"): Correct
	predicate to nonimmediate_operand from memory_operand for the
	operand that is to be forced to memory by the expander.  Lose
	the constraints.

Index: gcc/config/mmix/mmix.md
===================================================================
--- gcc/config/mmix/mmix.md	(revision 174376)
+++ gcc/config/mmix/mmix.md	(working copy)
@@ -625,8 +625,8 @@ (define_insn "fixuns_truncdfdi2"
 ;; define_expand with the old pattern as "anonymous".
 ;; FIXME: Perhaps with SECONDARY_MEMORY_NEEDED?
 (define_expand "truncdfsf2"
-  [(set (match_operand:SF 0 "memory_operand" "")
-	(float_truncate:SF (match_operand:DF 1 "register_operand" "")))]
+  [(set (match_operand:SF 0 "nonimmediate_operand")
+	(float_truncate:SF (match_operand:DF 1 "register_operand")))]
   ""
   "
 {
@@ -660,8 +660,8 @@ (define_insn "*truncdfsf2_real"

 ;; Same comment as for truncdfsf2.
 (define_expand "extendsfdf2"
-  [(set (match_operand:DF 0 "register_operand" "=r")
-	(float_extend:DF (match_operand:SF 1 "memory_operand" "m")))]
+  [(set (match_operand:DF 0 "register_operand")
+	(float_extend:DF (match_operand:SF 1 "nonimmediate_operand")))]
   ""
   "
 {

brgds, H-P

             reply	other threads:[~2011-06-06  4:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-06  4:10 Hans-Peter Nilsson [this message]
2011-06-07 14:24 ` Richard Sandiford

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=alpine.BSF.2.00.1106060006270.49583@dair.pair.com \
    --to=hp@bitrange.com \
    --cc=gcc-patches@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).