From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117409 invoked by alias); 23 Feb 2016 17:21:24 -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 117359 invoked by uid 89); 23 Feb 2016 17:21:23 -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_40,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*r:UNKNOWN, wint-conversion, Wint-conversion, wintconversion X-HELO: mail151.extendcp.co.uk Received: from mail151.extendcp.co.uk (HELO mail151.extendcp.co.uk) (79.170.40.151) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 23 Feb 2016 17:21:22 +0000 Received: from dmcbride-adsl.demon.co.uk ([62.49.26.146] helo=athena.lair) by mail151.extendcp.com with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.80.1) id 1aYGeE-0003em-21; Tue, 23 Feb 2016 17:21:18 +0000 Received: from sdb by athena.lair with local (Exim 4.86) (envelope-from ) id 1aYGeB-0005HS-HO; Tue, 23 Feb 2016 17:21:15 +0000 Date: Tue, 23 Feb 2016 17:21:00 -0000 From: Stuart Brady To: Joseph Myers Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] [PATCH] Add __array_size keyword Message-ID: <20160223172115.GA20061@zubnet.me.uk> References: <20160211200534.GA545@zubnet.me.uk> <20160213031649.GA465@zubnet.me.uk> <20160216152004.GA19262@zubnet.me.uk> <20160216232858.GA4401@zubnet.me.uk> <20160217002934.GA4916@zubnet.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160217002934.GA4916@zubnet.me.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-02/txt/msg01598.txt.bz2 On Wed, Feb 17, 2016 at 12:29:34AM +0000, Stuart Brady wrote: > > - should __array_size (b) be an integer constant (size_t)2, or should it > > be non-constant (size_t)2 because the argument is a VLA (albeit a VLA > > whose top-level dimension is an integer constant expression)? > > Ouch. I would say it should be an integer constant (size_t)2, simply as > that seems to me to be a reasonable expectation. Unfortunately, this is > not what happens with my patch, as I get a -Wint-conversion warning. :-( [snip] Okay. So, unsurprisingly, it turns out the problem here was in my code. When I added c_expr_array_size_expr() and c_expr_array_size_type() it seems I had not understood that C_TYPE_VARIABLE_SIZE and therefore also c_vla_type_p are non-zero (true) for VLAs where the outermost subscript is not variable, behaviour I can now clearly see in grokdeclarator(). This certainly supports the notion that test cases and documentation are of greater importance than the patch itself, at this stage. I now seem to have an __array_size keyword that behaves as I would expect in this case, too. I'll resubmit the patch once I have gone through the final draft of C11. It is still not entirely clear to me whether I must do something to prevent constant folding for use of __array_size with VLAs, but I am not so highly concerned just at the moment. -- Many thanks, Stuart Brady