From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32431 invoked by alias); 14 Feb 2020 20:06:54 -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 32419 invoked by uid 89); 14 Feb 2020 20:06:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:c65bc6b, H*f:sk:c65bc6b, H*MI:sk:c65bc6b, 85723 X-HELO: mail-qv1-f67.google.com Received: from mail-qv1-f67.google.com (HELO mail-qv1-f67.google.com) (209.85.219.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Feb 2020 20:06:52 +0000 Received: by mail-qv1-f67.google.com with SMTP id y2so4826042qvu.13 for ; Fri, 14 Feb 2020 12:06:52 -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=E2oLnBKQDDU7ICuidGdGw7NJmyj/zU9AxBxv+/xcJsQ=; b=eYoQdKLukq3URihtfIM3bPzCklnssCuv1F4+zc7KdZRvb44d1gc31sC9SkPZU6aTlk iabE23z8b+44v4r2tkNFNaYL312z0LyfVon4UM+5woGFSBz2LcXCrLInT3fzbMYTGadk 83vxCXmlNrqa2Cazmvy1FM7EDyeaFXex4yPFwR+koc57JTK8JvTYypr8jVyqc+thsZrB uvkT5562lDZ27A8Fab1lx64dP1olwSlieGOQkiyLQOJo1ICVcD6HdaWE6/NkvCozg4ZM +mbWJS284SkUW7IQJdmmWejZlINy3ZnrIPimmRWrPmGTWAHKfi9O9YMQLIKJwOryPAcW 2WuQ== Return-Path: Received: from [192.168.0.41] (174-16-112-158.hlrn.qwest.net. [174.16.112.158]) by smtp.gmail.com with ESMTPSA id d2sm1168668qko.110.2020.02.14.12.06.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Feb 2020 12:06:50 -0800 (PST) Subject: Re: [PATCH] avoid user-constructible types in reshape_init_array (PR 90938) To: Jason Merrill , gcc-patches References: From: Martin Sebor Message-ID: <32339bf2-7d63-66ec-7ffa-77086e84dfa5@gmail.com> Date: Fri, 14 Feb 2020 20:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.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: 2020-02/txt/msg00875.txt.bz2 On 2/13/20 3:59 PM, Jason Merrill wrote: > On 2/12/20 9:21 PM, Martin Sebor wrote: >> On 2/11/20 5:28 PM, Jason Merrill wrote: >>> On 2/11/20 9:00 PM, Martin Sebor wrote: >>>> r270155, committed in GCC 9, introduced a transformation that strips >>>> redundant trailing zero initializers from array initializer lists in >>>> order to support string literals as template arguments. >>>> >>>> The transformation neglected to consider the case of array elements >>>> of trivial class types with user-defined conversion ctors and either >>>> defaulted or deleted default ctors.  (It didn't occur to me that >>>> those qualify as trivial types despite the user-defined ctors.)  As >>>> a result, some valid initialization expressions are rejected when >>>> the explicit zero-initializers are dropped in favor of the (deleted) >>>> default ctor, >>> >>> Hmm, a type with only a deleted default constructor is not trivial, >>> that should have been OK already. >> >> For Marek's test case: >>    struct A { A () == delete; A (int) = delete; }; >> >> trivial_type_p() returns true (as does __is_trivial (A) in both GCC >> and Clang). >> >> [class.prop] says that >> >>    A trivial class is a class that is trivially copyable and has one >>    or more default constructors (10.3.4.1), all of which are either >>    trivial or deleted and at least one of which is not deleted. >> >> That sounds like A above is not trivial because it doesn't have >> at least one default ctor that's not deleted, but both GCC and >> Clang say it is.  What am I missing?  Is there some other default >> constructor hiding in there that I don't know about? >> >>>> and others are eliminated in favor of the defaulted >>>> ctor instead of invoking a user-defined conversion ctor, leading to >>>> wrong code. >>> >>> This seems like a bug in type_initializer_zero_p; it shouldn't treat >>> 0 as a zero initializer for any class. >> >> That does fix it, and it seems like the right solution to me as well. >> Thanks for the suggestion.  I'm a little unsure about the condition >> I put in place though. >> >> Attached is an updated patch rested on x86_64-linux. > >> -  if (sized_array_p && trivial_type_p (elt_type)) >> +  if (sized_array_p >> +      && trivial_type_p (elt_type) >> +      && !TYPE_NEEDS_CONSTRUCTING (elt_type)) > > Do we still need this change?  If so, please add a comment about the > trivial_type_p bug. The change isn't needed with my patch as it was, but it would still be needed with the changes you suggested (even then it doesn't help with the problem I describe below). > >>    if (TREE_CODE (init) != CONSTRUCTOR > I might change this to > >  if (!CP_AGGREGATE_TYPE_P (type)) >    return initializer_zerop (init); This behaves differently in C++ 2a mode (the whole condition evaluates to true for class A below) than in earlier modes and causes a failure in the new array55.C test: struct A { A () = delete; A (int) = delete; }; A a1[1] = { 0 }; // { dg-error "use of deleted function 'A::A\\\(int\\\)'" } because GCC ends up printing: error: use of deleted function 'A::A()' This is because A is considered trivial and TYPE_NEEDS_CONSTRUCTING is false. IIUC what Marek pointed to (CWG1496), A should not be considered trivial but GCC doesn't implement that change in the standard, hence the failure. >  else if (TREE_CODE (init) != CONSTRUCTOR) >    return false; > > and then remove the > >>   if (TYPE_NON_AGGREGATE_CLASS (type)) >>     return false; > > later in the function. > > More generally, this function could recognize when the initializer is > equivalent to {}-initialization and return true in that case, but that > sounds probably too tricky for stage 4. My preference is to leave the fix as it is (i.e., leave the test for RECORD_OR_UNION_TYPE_P in place), just with the TYPE_NEEDS_CONSTRUCTING test removed, and defer improvements until PR 85723 is fixed. Let me know how you want me to proceed. Martin