From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27136 invoked by alias); 7 Jan 2019 00:09:06 -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 27119 invoked by uid 89); 7 Jan 2019 00:09:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_MANYTO,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=ditto, Ditto, HContent-Transfer-Encoding:8bit X-HELO: mail-qk1-f172.google.com Received: from mail-qk1-f172.google.com (HELO mail-qk1-f172.google.com) (209.85.222.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Jan 2019 00:09:04 +0000 Received: by mail-qk1-f172.google.com with SMTP id g125so24493350qke.4 for ; Sun, 06 Jan 2019 16:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xnyh7sS5E5YNe+afaEU+Yn9+tW15n97NsQA5ZEMtS6g=; b=Kv+MLcrz/lPrJyT5UDVmF0hufXoFoKuT1lxXJHtp8rW88aK24yIoScVA44yM7hadi1 B6zeZ4R/qxMKWXXglZ9vfo04e6+KxB2KHttSgMKqsvNIsTkPkJS4MnaKZu6Y59C/5QXd s8H66+OV9oyhmbeMlhbFmG/yasWj9N282OH4y8GREYFro9n3jn/p8yCczkV5acy247GC 8Q2cEnY0bed8F30NIU7vXSCk32WWhwqBtVz0+tClB1K6b/t/o4aZGchjCsW5f25HHXPA edsr+OwQUm9FgqYEYZFoeoNIDtEyIQHHH6uQ6ss+TP10GjsowqSTHEQfyVwgGz6TPIFs Szzg== Return-Path: Received: from [192.168.0.106] (174-16-101-177.hlrn.qwest.net. [174.16.101.177]) by smtp.gmail.com with ESMTPSA id w81sm41793648qkg.43.2019.01.06.16.09.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Jan 2019 16:09:01 -0800 (PST) Subject: Re: [PATCH, C++,rebased] Fix PR c++/88261 To: Bernd Edlinger , Jason Merrill , Martin Sebor , "gcc-patches@gcc.gnu.org" , Jeff Law , Nathan Sidwell References: <4a92d8cf-a0da-67ac-d544-2c87f9d3a07e@redhat.com> <6f8f1380-1f13-007d-03e6-a2fe3d0d62f1@gmail.com> <18e39add-b0de-e476-86ba-3422dc911b6a@redhat.com> From: Martin Sebor Message-ID: <161cb6f1-f2cd-32b9-119c-fa5c6263d893@gmail.com> Date: Mon, 07 Jan 2019 00:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00260.txt.bz2 On 1/5/19 9:04 AM, Bernd Edlinger wrote: > On 1/4/19 10:22 PM, Jason Merrill wrote: >> Hmm, I'm uncomfortable with starting to pass in the decl just for the sake of deciding whether this diagnostic should be a pedwarn or error. In general, because of copy elision, we can't know at this point what we're initializing, so I'd rather not pretend we can.  Instead, maybe add a LOOKUP_ALLOW_FLEXARY_INIT flag that you can add to the flags argument in the call from store_init_value? >> > > Okay, I reworked the patch, to pass a bit in the flags, it was a bit more complicated > than anticipated, because it is necessary to pass the flag thru process_init_constructor > and friends to the recursive invocation of digest_init_r. It turned out that > digest_nsdmi_init did not need to change, since it is always wrong to use flexarray init > there. I added a new test case (flexary32.C) to exercises a few cases where non static > direct member intializers are allowed to use flexarrays (in static members) and where that > would be wrong (in automatic members). So that seems to work. If that resolves pr69338 can you please also reference the bug in the test and in the ChangeLog? (Ditto for pr69697.) Martin > > New version of the patch is attached. > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? > > > Thanks > Bernd. >