From patchwork Tue Oct 22 13:50:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 285426 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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 589A52C00C1 for ; Wed, 23 Oct 2013 00:50:17 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:content-type:from:to:cc:subject:date:in-reply-to :references:mime-version; q=dns; s=default; b=ThIklas/DhFADiNpEF TjR8zCUozX6HVh0lJozDrg31tI8vNR8tjtN1Nhhsbf6pRXBNP9xEGV/hRzRfK6Jt 8500FdHwMwkxIBUt7X7GABYjGTNHlJf8DHDSvi3s7uCiGocdB1ZAm0YE19pjSiBU IC5bMJOQ5MugfO0gYiWIWFPXI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:content-type:from:to:cc:subject:date:in-reply-to :references:mime-version; s=default; bh=KB01a0NEVAwUp/OQ5PHKNVEM gpI=; b=dhIQ6le78ws56V3uQ0GUAVd2q24Fv2SpPtBhm3dqAfC08VhB8vgYEubD 14vt3TgFCqUhJZ/VwCGBlmnDyPXvfA2df6zilWgSHB9Ux8ZeEJDZM+dZd0FMZ0fx WVT6/X4LWYtxvbrbywy/YL2u32JxgWUoSMRKoT1lPYZr9g8Xrpo= Received: (qmail 31650 invoked by alias); 22 Oct 2013 13:50:10 -0000 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 Received: (qmail 31637 invoked by uid 89); 22 Oct 2013 13:50:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 X-HELO: dub0-omc1-s6.dub0.hotmail.com Received: from dub0-omc1-s6.dub0.hotmail.com (HELO dub0-omc1-s6.dub0.hotmail.com) (157.55.0.205) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Oct 2013 13:50:08 +0000 Received: from DUB122-W20 ([157.55.0.239]) by dub0-omc1-s6.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Oct 2013 06:50:06 -0700 X-TMN: [q3aUxVb56dcuY1P5xx4HZez+/jfhV3/T] Message-ID: From: Bernd Edlinger To: Martin Jambor CC: Richard Biener , GCC Patches , Eric Botcazou Subject: RE: [PATCH, PR 57748] Check for out of bounds access Date: Tue, 22 Oct 2013 15:50:05 +0200 In-Reply-To: <20130916230945.GK6732@virgil.suse> References: , , , , , , <20130910193228.GE6732@virgil.suse>, , , , <20130916230945.GK6732@virgil.suse> MIME-Version: 1.0 Hi, On Tue, 17 Sep 2013 01:09:45, Martin Jambor wrote: >> @@ -4773,6 +4738,8 @@ expand_assignment (tree to, tree from, b >>        if (MEM_P (to_rtx) >>            && GET_MODE (to_rtx) == BLKmode >>            && GET_MODE (XEXP (to_rtx, 0)) != VOIDmode >> +          && bitregion_start == 0 >> +          && bitregion_end == 0 >>            && bitsize> 0 >>            && (bitpos % bitsize) == 0 >>            && (bitsize % GET_MODE_ALIGNMENT (mode1)) == 0 >> > ... > > I'm not sure to what extent the hunk adding tests for bitregion_start > and bitregion_end being zero is connected to this issue. I do not see > any of the testcases exercising that path. If it is indeed another > problem, I think it should be submitted (and potentially committed) as > a separate patch, preferably with a testcase. > Meanwhile I am able to give an example where that code is executed with bitpos = 64, bitsize=32, bitregion_start = 32, bitregion_end = 95. Afterwards bitpos=0, bitsize=32, which is completely outside bitregion_start=32, bitregion_end=95. However this can only be seen in the debugger, as the store_field goes thru a code path that does not look at bitregion_start/end. Well that is at least extremely ugly, and I would not be sure, that I cannot come up with a sample that crashes or creates wrong code. Currently I think that maybe the best way to fix that would be this: Any suggestions? Regards Bernd. extern void abort (void); struct x{ int a; int :32; volatile int b:32; }; struct s { int a,b,c,d; struct x xx[1]; }; struct s ss; volatile int k; int main() { ss.xx[k].b = 1; // asm volatile("":::"memory"); if ( ss.xx[k].b != 1) abort (); return 0; } --- gcc/expr.c    2013-10-21 08:27:09.546035668 +0200 +++ gcc/expr.c    2013-10-22 15:19:56.749476525 +0200 @@ -4762,6 +4762,9 @@ expand_assignment (tree to, tree from, b            && MEM_ALIGN (to_rtx) == GET_MODE_ALIGNMENT (mode1))          {            to_rtx = adjust_address (to_rtx, mode1, bitpos / BITS_PER_UNIT); +          bitregion_start = 0; +          if (bitregion_end>= (unsigned HOST_WIDE_INT) bitpos) +        bitregion_end -= bitpos;            bitpos = 0;          }