From patchwork Thu Feb 21 06:28:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 222187 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 CA7AF2C008D for ; Thu, 21 Feb 2013 17:29:04 +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=1362032946; 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=hWg/m4p6up87xrJY8Hm0 Fd+og7Q=; b=cqf4xbaZQo7aG/OYYtZ9N8bqDWtVBY40koh3bQyECVkGIYechXhY e4jP77LWwusjw+HHATeCU05r1UgYJDwMNtldhmHsJgq5IlP8+43ds/OL+MF5aJAw +pSBSXHKHK1jk3rQX+c3msryN7IOOyV+QpgP6DPbyzKP5LBdzRqyMXk= 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=bMrO9Gjdb4L4UXyA3pBaKMIhVEMgMAoh9y6w/JC4lTeT1YTnw5egp8SUhAt8q3 tsq/u5mZ8IYMbpjg8l4Oy69indFO4sVx6Mkcj0W4wpFFKL/SyR68bmieAG7Kr55Y aUEuxMFW/IZ+UXVtcYjzn0+Jx0oQUwWWpqLXKFBqRUNJ8=; Received: (qmail 17128 invoked by alias); 21 Feb 2013 06:28:57 -0000 Received: (qmail 17120 invoked by uid 22791); 21 Feb 2013 06:28:56 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS 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; Thu, 21 Feb 2013 06:28:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1L6SkJW022501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 01:28:46 -0500 Received: from zalov.redhat.com (vpn1-7-92.ams2.redhat.com [10.36.7.92]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1L6SiQN027913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 01:28:45 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r1L6ShJp007965; Thu, 21 Feb 2013 07:28:43 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r1L6SgOs007964; Thu, 21 Feb 2013 07:28:42 +0100 Date: Thu, 21 Feb 2013 07:28:42 +0100 From: Jakub Jelinek To: Richard Biener , Jeff Law , Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Don't expand *MEM_REF using extract_bit_field or movmisalign for EXPAND_MEMORY (PR inline-asm/56405) Message-ID: <20130221062842.GU1215@tucnak.zalov.cz> 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! If an input operand of inline-asm doesn't allow registers, but allows memory, we expand it with EXPAND_MEMORY modifier (the only case of using that modifier). But the movmisalign code added for 4.6 and especially the extract_bit_field code added for 4.8 results in getting a REG from expand_expr called with a *MEM_REF with EXPAND_MEMORY, instead of MEM the caller expects and can only handle, therefore we ICE. This patch fixes it by honoring EXPAND_MEMORY in these cases, it is the sole responsibility of the inline asm writer to do the right thing in there for misaligned mems (e.g. gcc could pessimistically expect it might be misaligned, but user knows it will not). Bootstrapped/regtested on {x86_64,i686,armv7hl,ppc,ppc64,s390,s390x}-linux, ok for trunk? 2013-02-21 Jakub Jelinek PR inline-asm/56405 * expr.c (expand_expr_real_1) : Don't use movmisalign or extract_bit_field for EXPAND_MEMORY modifier. * gcc.c-torture/compile/pr56405.c: New test. Jakub --- gcc/expr.c.jj 2013-01-18 18:09:40.000000000 +0100 +++ gcc/expr.c 2013-02-20 10:29:34.513143634 +0100 @@ -9551,6 +9551,7 @@ expand_expr_real_1 (tree exp, rtx target set_mem_addr_space (temp, as); align = get_object_alignment (exp); if (modifier != EXPAND_WRITE + && modifier != EXPAND_MEMORY && mode != BLKmode && align < GET_MODE_ALIGNMENT (mode) /* If the target does not have special handling for unaligned @@ -9639,6 +9640,7 @@ expand_expr_real_1 (tree exp, rtx target if (TREE_THIS_VOLATILE (exp)) MEM_VOLATILE_P (temp) = 1; if (modifier != EXPAND_WRITE + && modifier != EXPAND_MEMORY && mode != BLKmode && align < GET_MODE_ALIGNMENT (mode)) { --- gcc/testsuite/gcc.c-torture/compile/pr56405.c.jj 2013-02-20 10:32:17.807250979 +0100 +++ gcc/testsuite/gcc.c-torture/compile/pr56405.c 2013-02-20 10:32:46.963090873 +0100 @@ -0,0 +1,7 @@ +/* PR inline-asm/56405 */ + +void +foo (void) +{ + asm volatile ("" : "+m" (*(volatile unsigned short *) 0x1001UL)); +}