From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92425 invoked by alias); 30 Jul 2018 13:36:42 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 92407 invoked by uid 89); 30 Jul 2018 13:36:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: SMTP03.CITRIX.COM Received: from smtp03.citrix.com (HELO SMTP03.CITRIX.COM) (162.221.156.55) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Jul 2018 13:36:40 +0000 Date: Mon, 30 Jul 2018 13:47:00 -0000 From: Wei Liu To: U.Mutlu CC: Wei Liu , Subject: Re: Gcc 8.1, -O2 optimisation build failure Message-ID: <20180730133636.sjrhneyjmn7ilg2n@citrix.com> References: <20180730080831.vf25eawbpygnfas2@citrix.com> <5B5F0BBB.8090404@mutluit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5B5F0BBB.8090404@mutluit.com> User-Agent: NeoMutt/20170113 (1.7.2) Return-Path: wei.liu2@citrix.com X-SW-Source: 2018-07/txt/msg00252.txt.bz2 On Mon, Jul 30, 2018 at 02:59:39PM +0200, U.Mutlu wrote: > I think there's a mismatch with decimal and hexadecimal values. > You suggested that -204 is actually 0xffffff34, right? We considered that, too. > Write/simulate testcases for some border cases of offset, for example 0, > 128, 256, 512, 768. It seems that the line offset -= 0xcc is triggering this behaviour. Changing 0xcc to other values causes the bounds to change. Suppose offset underflows, the if statement becomes true, memcpy won't be invoked at all. In that case, why would gcc complain the indices are out of bounds? Further pointers are appreciated. Wei. > > > Wei Liu wrote on 07/30/2018 10:08 AM: > > Hello, > > > > We have a program which fails to build with gcc 8.1 -m32 -O2 (version > > Debian 8.1.0-12). We couldn't figure out how the optimiser came up with > > the idea that array bounds could become negative. Any help would be > > appreciated. The attached code has been simplified from the original to > > reproduce the issue. > > > > The same code snippet builds find with 8.1 debug build and older > > versions of gcc. > > > > $ gcc -m32 -march=i686 -std=gnu99 -Wall -O2 -Werror -c -o t.o t.c > > t.c: In function 'func': > > t.c:41:9: error: 'memcpy' offset [-204, -717] is out of the bounds [0, 216] of object 'ctrl' with type 'struct kdd_ctrl' [-Werror=array-bounds] > > memcpy(buf, ((uint8_t *)&ctrl.c32) + offset, len); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > t.c:27:21: note: 'ctrl' declared here > > struct kdd_ctrl ctrl; > > > > > > #include > > #include > > > > struct kdd_ctrl_32 { > > uint8_t _[84]; > > }; > > > > struct kdd_ctrl_64 { > > uint8_t _[216]; > > }; > > > > struct kdd_ctrl { > > union { > > struct kdd_ctrl_32 c32; > > struct kdd_ctrl_64 c64; > > }; > > }; > > > > typedef struct { > > uint8_t buf[17 + 65536]; > > uint32_t length_req; > > uint64_t addr; > > } kdd_state; > > > > void func(kdd_state *s) > > { > > struct kdd_ctrl ctrl; > > uint8_t *buf = s->buf + 17 + 57; > > uint32_t len = s->length_req; > > uint64_t addr = s->addr; > > > > uint32_t offset = addr; > > > > /* 32-bit control-register space starts at 0x[2]cc, for 84 bytes */ > > if (offset > 0x200) > > offset -= 0x200; > > offset -= 0xcc; > > if (offset > sizeof ctrl.c32 || offset + len > sizeof ctrl.c32) { > > len = 0; > > } else { > > memcpy(buf, ((uint8_t *)&ctrl.c32) + offset, len); > > } > > } > > > > > > Regards, > > Wei. > > >