From patchwork Fri Jan 20 17:16:14 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 137047 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 3AD2AB6EFE for ; Sat, 21 Jan 2012 04:16:45 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1327684606; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=AYZylx1kgNrf9E8xa9Ex IQzxPOg=; b=XeL+aPBHGuKQlSn5fDpZPS2y4IumIxLKzBiB9GkDE6MMWmOMECe5 8Hu1kpreZTrWj0Pa8jLejLJXV27V2aia4niggj+MM7mlIVgm2zF2RtctqyLC7Hw1 5jb1h2FX7yfUdOt3n/IHJUrjwEGosxIALOhn7WirPaxsEUjAWmoteTc= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=xzaAEsNuVF8cQv2yQdPoW8x0DWdWgu8OL4gsxRSdqa36o+Lw1NDMB5s1g1d96/ 9RHo7f6lUA9eWP23nTgnjqt2vyRzT3B5bs2Y2oKKPbMxR3l5aPOlAGgestW3xIiY EPGmhVaz7686F8bWTeObAaQUIq4q1clMV49ZtWlzRG1GY=; Received: (qmail 26559 invoked by alias); 20 Jan 2012 17:16:38 -0000 Received: (qmail 26542 invoked by uid 22791); 20 Jan 2012 17:16:34 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jan 2012 17:16:21 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0KHGGGB018259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 12:16:17 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0KHGG4u013280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jan 2012 12:16:16 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id q0KHGFFd017812; Fri, 20 Jan 2012 18:16:15 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id q0KHGEAf017810; Fri, 20 Jan 2012 18:16:14 +0100 Date: Fri, 20 Jan 2012 18:16:14 +0100 From: Jakub Jelinek To: Ramana Radhakrishnan Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix arm ICE in output_move_double (PR target/51915) Message-ID: <20120120171614.GA18768@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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 Hi! As detailed in the PR, output_move_double sometimes modifies the operands array it is called on (when it intends to return a template string that should be output by the caller). Unfortunately, since arm_count_output_move_double_insns has been added, this can lead into clobbering of recog_data.operands already during computation of insn sizes, and if no other insn is recognized in between that and the output of that insn, we might be called with second operand of SImode r1 instead of a MEM and ICE, because it sees a DImode r0 = SImode r1 move. Fixed thusly, ok for trunk? 2012-01-20 Jakub Jelinek PR target/51915 * config/arm/arm.c (arm_count_output_move_double_insns): Call output_move_double on a copy of operands array. * gcc.target/arm/pr51915.c: New test. Jakub --- gcc/config/arm/arm.c.jj 2012-01-20 12:35:15.000000000 +0100 +++ gcc/config/arm/arm.c 2012-01-20 13:51:06.781889121 +0100 @@ -24664,7 +24664,12 @@ int arm_count_output_move_double_insns (rtx *operands) { int count; - output_move_double (operands, false, &count); + rtx ops[2]; + /* output_move_double may modify the operands array, so call it + here on a copy of the array. */ + ops[0] = operands[0]; + ops[1] = operands[1]; + output_move_double (ops, false, &count); return count; } --- gcc/testsuite/gcc.target/arm/pr51915.c.jj 2012-01-20 14:04:38.036245754 +0100 +++ gcc/testsuite/gcc.target/arm/pr51915.c 2012-01-20 14:04:21.000000000 +0100 @@ -0,0 +1,13 @@ +/* PR target/51915 */ +/* { dg-do compile } */ +/* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */ + +struct S { int s1; void *s2; }; +struct T { struct S t1; unsigned long long t2; }; +struct S *foo (unsigned long long); + +struct S * +bar (struct S *x) +{ + return foo (((struct T *) x)->t2); +}