From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79308 invoked by alias); 7 Apr 2015 14:18:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 79272 invoked by uid 89); 7 Apr 2015 14:18:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Apr 2015 14:18:20 +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 (Postfix) with ESMTPS id F246EAC7A8; Tue, 7 Apr 2015 14:18:18 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-58.ams2.redhat.com [10.36.116.58]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37EIHjA002836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Apr 2015 10:18:18 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t37EIFcx028645; Tue, 7 Apr 2015 16:18:16 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t37EIDDZ028644; Tue, 7 Apr 2015 16:18:13 +0200 Date: Tue, 07 Apr 2015 14:18:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix get_inner_reference (PR middle-end/65680) Message-ID: <20150407141813.GG19273@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00248.txt.bz2 Hi! bit_offset in get_inner_reference is offset_int (i.e. a wide_int larger than address size). get_inner_reference has code to handle the case when bit_offset is negative by splitting it into a byte offset and very small positive bitpos, but on the following testcase bit_offset isn't negative, just is too large to fit into shwi, so to the caller it incorrectly appears to be negative. This patch fixes it by handling it the same, putting the large part into offset and just the remaining bits into bitpos in that case. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2015-04-07 Jakub Jelinek PR middle-end/65680 * expr.c (get_inner_reference): Handle bit_offset that doesn't fit into signed HOST_WIDE_INT the same as negative bit_offset. * gcc.c-torture/compile/pr65680.c: New test. --- gcc/expr.c.jj 2015-03-16 17:06:30.000000000 +0100 +++ gcc/expr.c 2015-04-07 10:16:10.365876617 +0200 @@ -6941,7 +6941,7 @@ get_inner_reference (tree exp, HOST_WIDE if (offset) { /* Avoid returning a negative bitpos as this may wreak havoc later. */ - if (wi::neg_p (bit_offset)) + if (wi::neg_p (bit_offset) || !wi::fits_shwi_p (bit_offset)) { offset_int mask = wi::mask (LOG2_BITS_PER_UNIT, false); offset_int tem = bit_offset.and_not (mask); --- gcc/testsuite/gcc.c-torture/compile/pr65680.c.jj 2015-04-07 10:25:40.142632657 +0200 +++ gcc/testsuite/gcc.c-torture/compile/pr65680.c 2015-04-07 10:25:08.000000000 +0200 @@ -0,0 +1,20 @@ +/* PR middle-end/65680 */ +/* { dg-do compile { target lp64 } } */ + +struct S +{ + int f : 1; +} a[100000000000000001][3]; + +void +foo (void) +{ + struct S b = { 0 }; + a[100000000000000000][0] = b; +} + +void +bar (void) +{ + a[100000000000000000][0].f = 1; +} Jakub