From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7056 invoked by alias); 24 Oct 2013 07:15:55 -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 7042 invoked by uid 89); 24 Oct 2013 07:15:54 -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-s30.dub0.hotmail.com Received: from dub0-omc1-s30.dub0.hotmail.com (HELO dub0-omc1-s30.dub0.hotmail.com) (157.55.0.229) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Oct 2013 07:15:53 +0000 Received: from DUB122-W18 ([157.55.0.239]) by dub0-omc1-s30.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 00:15:50 -0700 X-TMN: [waT/W06holL0rqJjWTgwnB+h4PsI9l1j] Message-ID: From: Bernd Edlinger To: Martin Jambor , Richard Biener CC: Eric Botcazou , "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH, PR 57748] Check for out of bounds access, Part 2 Date: Thu, 24 Oct 2013 08:20:00 -0000 In-Reply-To: <20131023171106.GC22314@virgil.suse> References: <20130910193228.GE6732@virgil.suse>,<2557640.s7jgdhfLQs@polaris>,,<2243204.JyA3NMmzTd@polaris>,,,,<20131023171106.GC22314@virgil.suse> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-10/txt/msg01983.txt.bz2 Hi Martin, On Wed, 23 Oct 2013 19:11:06, Martin Jambor wrote: > On Wed, Oct 23, 2013 at 06:00:43PM +0200, Richard Biener wrote: >> > > ... > >> ? And why should the same issue not exist for >> >> struct { V a[1]; } >> > > indeed, it does and it's simple to trigger (on x86_64): > > ---------------------------------------- > /* { dg-do run } */ > > #include > > typedef long long V > __attribute__ ((vector_size (2 * sizeof (long long)), may_alias)); > > #if 1 > typedef struct S {V b[1]; } P __attribute__((aligned (1))); > struct __attribute__((packed)) T { char c; P s; }; > #else > typedef struct S {V b[1]; } P; > struct T { char c; P s; }; > #endif > > void __attribute__((noinline, noclone)) > good_value (V b) > { > if (b[0] !=3D 3 || b[1] !=3D 4) > __builtin_abort (); > } > > void __attribute__((noinline, noclone)) > check (P *p) > { > good_value (p->b[1]); > } > > int > main () > { > struct T *t =3D (struct T *) calloc (128, 1); > V a =3D { 3, 4 }; > t->s.b[1] =3D a; > check (&t->s); > free (t); > return 0; > } > ---------------------------------------- > > While I was willing to discount the zero sized array as an > insufficiently specified oddity, this seems to be much more serious > and potentially common. It seems we really need to be able to detect > these out-of-bounds situations and tell lower levels of expander that > "whatever mode you think you are expanding, it is actually BLK mode." > > It's uglier than I thought. > > Martin > Deja-vu... Thanks for this test case. This definitely destroys the idea to fix this in= stor-layout.c I think that is common practice to write array[1]; at the end of the struct= ure, and use it as a flexible array. The compute_record_mode has no way to decide if that is going to be a flexible array or not. Sorry Eric, but now I have no other choice than to go back to my previous v= ersion of part 2: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00222.html I'd just add Martin's new test case as 57748-4.c. Bernd.=20=09=09=20=09=20=20=20=09=09=20=20