From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70059 invoked by alias); 27 Jan 2016 16:52:20 -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 70015 invoked by uid 89); 27 Jan 2016 16:52:19 -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=Hx-languages-length:1855, risk, vla X-HELO: mail-qg0-f68.google.com Received: from mail-qg0-f68.google.com (HELO mail-qg0-f68.google.com) (209.85.192.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 27 Jan 2016 16:52:18 +0000 Received: by mail-qg0-f68.google.com with SMTP id 6so860949qgy.3 for ; Wed, 27 Jan 2016 08:52:17 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4h4PeSVWSG8AxmQkEU5je43JQhlsxmUe53Yde7gHkQY=; b=e8KyosiWKr5hIBUF6oSJ7r6bnUzqtBHuvgVGx4dVQRtLFDfGZu+J44Z2ew6B9FcJvk gi4+juMfO31RJvFWJvQPYH+/24EzOLHg71N+GPZvwsbQXguIHTWAxoLE1zAnC/2HzfZ8 PWsYyAZIDz14/2KNTzFaVOgfZNJRU4RqLX2oIB62jSpjguCA5yrdHWipCojct7f0uWC9 R2WRqn7LRSv/G+OpwYiFPHayYoyetx3OHCcSsqP7AyPs7ziOYJ9rMItJdoVNJ/yx8NzD O9UNPlTM7bjhv2ntvJIWmcSAd6hj0vm5fTgPWvnkePmnuI7pUBpGJ2IEevkwmqB8dFu+ kPmQ== X-Gm-Message-State: AG10YOQdhkraW6FWV5y3Qd2KEA+7Jimbn0vEXB+YXzqX1vwBu2m0BDCcDd7Ri7f5UobPVg== X-Received: by 10.140.176.206 with SMTP id w197mr37590587qhw.59.1453913536071; Wed, 27 Jan 2016 08:52:16 -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 y129sm1978436qka.33.2016.01.27.08.52.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jan 2016 08:52:15 -0800 (PST) Message-ID: <56A8F5BD.4010104@gmail.com> Date: Wed, 27 Jan 2016 16:52: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 CC: GCC Patches , Jason Merrill Subject: Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function) References: <20160126230246.GO25528@redhat.com> <56A8404E.9030005@gmail.com> <20160127111954.GQ25528@redhat.com> In-Reply-To: <20160127111954.GQ25528@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg02135.txt.bz2 >> 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. > > I don't think we can do this at this time. E.g. the following program works > even with GCC 5 and -std=c++14: > > constexpr int > foo (int n) > { > int a[n] = { 1, 2, 3 }; > int z = 0; > for (unsigned i = 0; i < 3; ++i) > z += a[i]; > return z; > } > > int > main () > { > constexpr int n = foo (3); > __builtin_printf ("%d\n", n); > } This happens to work but I suspect it's only by accident. When the number of elements in the initializer is increased to exceed the number of elements in the VLA GCC gets into infinite recursion. (I opened bug 69516 with a test case). The same error in a non- constexpr function causes a SEGV at runtime (this is also a regression WRT 4.9.3 -- I opened bug 69517 for it). > So starting to reject such a code might broke working programs. And we're > able to reject non-standard code: -pedantic-errors. I agree that there is some risk that it might break some working programs. I would expect the most common use of initialized VLAs be to set all elements to zero using the "= { }" or "= { 0 }" syntax. Initializers with more elements are, IMO, likely to be a bug where the user doesn't realize they defined a VLA rather than an ordinary array. Since VLAs are required to have at least 1 element, would diagnosing initializers with more than one element more loudly (such as by default or with -Wall as opposed to with -Wpedantic) be a good solution? Martin