From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103674 invoked by alias); 27 Jan 2016 03:58:14 -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 103655 invoked by uid 89); 27 Jan 2016 03:58:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=risk, vla X-HELO: mail-qk0-f170.google.com Received: from mail-qk0-f170.google.com (HELO mail-qk0-f170.google.com) (209.85.220.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 27 Jan 2016 03:58:11 +0000 Received: by mail-qk0-f170.google.com with SMTP id s5so72436149qkd.0 for ; Tue, 26 Jan 2016 19:58:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JJcNgCd4vZvI0d0yk34LMNnrp/59v81YlmCBoS44nkQ=; b=Gz3FP6Pmh5YDvs5SkZeyEivSRxt/dchqY5niSZxIoeWYhjn60cI+rMPmfUUzc02VHI em/OZbjuTCGsClGj3SY85E/8PS+xGJaUzc+3uIXkc99COF/Ug7OLgAo06f0gIxJqF1Bm HThO/GL+Y2rj8+tjDDvZ0K7e8Fqh9uJITJp/eTjJJKBqXaZfnp2mHinI3FPdnks627pK WPYRgOJVGdtBrqX8KcSAMlnh0meus5uOdaTPrYwRSds+L26ruGe/YxIax1vLm7dLchY4 Gf86iAu1j5dWuC/gpFabSObkEDJdVTkJWrQX/tcYzZVD7EoP5bm46egnHr0ta03QEW4a +s6w== X-Gm-Message-State: AG10YORoKErv+IkWF+AA9aazApBFVfIb2pV0cZgkzW4/cPEln9gr7TnZfCxV3OcSUIfjWQ== X-Received: by 10.55.71.135 with SMTP id u129mr33376386qka.26.1453867089291; Tue, 26 Jan 2016 19:58:09 -0800 (PST) Received: from [192.168.0.26] (71-212-229-169.hlrn.qwest.net. [71.212.229.169]) by smtp.gmail.com with ESMTPSA id 189sm1620215qhg.13.2016.01.26.19.58.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jan 2016 19:58:08 -0800 (PST) Message-ID: <56A8404E.9030005@gmail.com> Date: Wed, 27 Jan 2016 03:58:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Marek Polacek , GCC Patches , Jason Merrill Subject: Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function) References: <20160126230246.GO25528@redhat.com> In-Reply-To: <20160126230246.GO25528@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg02069.txt.bz2 On 01/26/2016 04:02 PM, Marek Polacek wrote: > The (invalid) testcase was causing an ICE because we were passing the result > of array_type_nelts_top immediately into tree_int_cst_lt, but for VLAs, the > result doesn't have to be a constant. Fixed by evaluating the bound of the > array so that we're able to give a proper out-of-bounds diagnostics. And the > VERIFY_CONSTANT should ensure that if the array bound couldn't be reduced to > a constant, we bail out rather than evoke an ICE. Wow, you are quick! :) I wonder if it might be better to instead reject VLAs in constexpr functions altogether. Not because they're not in C++, but because C (or gcc) doesn't allow them to be initialized (and so accepting an initialized VLA is a g++ extension of an extension), and because in constexpr functions they are rejected without initialization just like other uninitialized variables. FWIW, it seems to me the fewer extensions we support the less risk of something going wrong because of unforeseen interactions with other features. Martin