From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13539 invoked by alias); 7 Nov 2015 23:38:16 -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 13516 invoked by uid 89); 7 Nov 2015 23:38:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 07 Nov 2015 23:38:14 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id tA7Nc5qc021395; Sat, 7 Nov 2015 17:38:05 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id tA7Nc4uJ021392; Sat, 7 Nov 2015 17:38:04 -0600 Date: Sat, 07 Nov 2015 23:38:00 -0000 From: Segher Boessenkool To: Joseph Myers Cc: Bernd Schmidt , Martin Sebor , Gcc Patch List Subject: Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof Message-ID: <20151107233804.GB9982@gate.crashing.org> References: <56172C8C.2070202@gmail.com> <5620ED47.2090009@redhat.com> <56215158.5040404@gmail.com> <56263F80.1090203@t-online.de> <56265E51.4070009@gmail.com> <5626A5A0.7040003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00824.txt.bz2 On Tue, Oct 20, 2015 at 10:10:44PM +0000, Joseph Myers wrote: > > typedef struct FA5_7 { > > int i; > > char a5_7 [5][7]; > > } FA5_7; > > > > __builtin_offsetof (FA5_7, a5_7 [0][7]), // { dg-warning "index" } > > __builtin_offsetof (FA5_7, a5_7 [1][7]), // { dg-warning "index" } > > __builtin_offsetof (FA5_7, a5_7 [5][0]), // { dg-warning "index" } > > __builtin_offsetof (FA5_7, a5_7 [5][7]), // { dg-warning "index" } > > > > Here I think the last one of these is most likely invalid (being 8 bytes past > > the end of the object, rather than just one) and the others valid. Can you > > confirm this? (If the &a.v[2].a example is considered invalid, then I think > > the a5_7[5][0] test would be the equivalent and ought to also be considered > > invalid). > > The last one is certainly invalid. The one before is arguably invalid as > well (in the unary '&' equivalent, &a5_7[5][0] which is equivalent to > a5_7[5] + 0, the questionable operation is implicit conversion of a5_7[5] > from array to pointer - an array expression gets converted to an > expression "that points to the initial element of the array object", but > there is no array object a5_7[5] here). C11, 6.5.2.1/3: Successive subscript operators designate an element of a multidimensional array object. If E is an n-dimensional array (n >= 2) with dimensions i x j x . . . x k, then E (used as other than an lvalue) is converted to a pointer to an (n - 1)-dimensional array with dimensions j x . . . x k. If the unary * operator is applied to this pointer explicitly, or implicitly as a result of subscripting, the result is the referenced (n - 1)-dimensional array, which itself is converted into a pointer if used as other than an lvalue. It follows from this that arrays are stored in row-major order (last subscript varies fastest). As far as I see, a5_7[5] here is never treated as an array, just as a pointer, and &a5_7[5][0] is valid. Segher