From patchwork Mon Jun 6 04:09:48 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 98794 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 68C33B6FA8 for ; Mon, 6 Jun 2011 14:10:10 +1000 (EST) Received: (qmail 4015 invoked by alias); 6 Jun 2011 04:10:05 -0000 Received: (qmail 3863 invoked by uid 22791); 6 Jun 2011 04:10:03 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from dair.pair.com (HELO dair.pair.com) (209.68.1.49) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Mon, 06 Jun 2011 04:09:49 +0000 Received: (qmail 84920 invoked by uid 20157); 6 Jun 2011 04:09:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Jun 2011 04:09:48 -0000 Date: Mon, 6 Jun 2011 00:09:48 -0400 (EDT) From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org Subject: Committed: fix PR49285, breakage building libgcc2 for MMIX Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org 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. brgds, H-P 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")))] "" " {