From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 2DBB3384C007 for ; Tue, 13 Jul 2021 18:37:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2DBB3384C007 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-13-WEzerU0cOIGrMnsZ1mPEvQ-1; Tue, 13 Jul 2021 14:37:46 -0400 X-MC-Unique: WEzerU0cOIGrMnsZ1mPEvQ-1 Received: by mail-qv1-f69.google.com with SMTP id bk10-20020a05621406eab02902d1aac9c421so4951945qvb.1 for ; Tue, 13 Jul 2021 11:37:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GfosYR7RbJIQd1dy+4+ImQwOIXwPmf81got9FUVpW8o=; b=Tp0POJyuFWZW3B6BoVPbzjc352Kn9SPYaIfjQhHwuWpV2wCRVUTfGnXDUyuK2zEKRN AySaEfDfBzo06KFHM089osHIXb1c+YV2pIuPEikIDl3IBKFlwA5Fq/OjwbsmjMv8OTZE Hd+VA8hc42PT4dJPC/B0z67thBNCa11BY/Sd3rNwIgmOd09vYMdsgR74j7416Adr2b+1 alsnuPL7Aur+VCyxbJdFVsraTsadyoMbcCfzFZNHZJJlFy3cI68Dm0MWJ0evSog6GmNy mPixKqBHK0XPYanvzaP8yJC2iguNLhv+cmHDQO1hJnqlndG2PdvDB04G7vSwmFn9+E3f DnAA== X-Gm-Message-State: AOAM530ar8lzwogTWkSLjXSTGZnjSOGzwHtQLdKpmZBfFjDX11dYyKjl pJ2nwQtb5NB82H62kjvu6iKWp0zPZWfzgw+w86Z4FxaRKhAcZCY4Jq2OZrRB981GTBvwt0K/f7N BJy0x4TWkxkW0CliLbM/A8FOk4zenJcTS0bzwVjDx1LuYUewcxRHjNWWsp7qrzuoMYw== X-Received: by 2002:ac8:6a03:: with SMTP id t3mr5185113qtr.45.1626201465461; Tue, 13 Jul 2021 11:37:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2NhXFi61QBRWceA187RuA3pGfYRspnxC3lNbH2h2JPEO/4BAZ/WvNBq9/kiArSdcSA1NcoA== X-Received: by 2002:ac8:6a03:: with SMTP id t3mr5185087qtr.45.1626201465093; Tue, 13 Jul 2021 11:37:45 -0700 (PDT) Received: from [192.168.1.148] (130-44-159-43.s11817.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id 197sm3118586qkn.64.2021.07.13.11.37.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 11:37:44 -0700 (PDT) Subject: Re: [PING][PATCH] define auto_vec copy ctor and assignment (PR 90904) To: Jonathan Wakely , Richard Biener Cc: Martin Sebor , gcc-patches References: <91545a73-12af-33b2-c6e7-119b5a21de60@gmail.com> <4d503394-4e82-1d36-41ca-34315042775b@redhat.com> <49569f1d-9856-55c7-b9e9-578bbd7c7b7a@gmail.com> <390c6652-0a1f-e8c4-d70d-56ced2f7b0fb@gmail.com> From: Jason Merrill Message-ID: <0ee2488c-04a1-df3b-dd4f-92eec51a4ab2@redhat.com> Date: Tue, 13 Jul 2021 14:37:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 18:37:49 -0000 On 7/13/21 10:08 AM, Jonathan Wakely wrote: > On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote: >> Somebody with more C++ knowledge than me needs to approve the >> vec.h changes - I don't feel competent to assess all effects of the change. > > They look OK to me except for: > > -extern vnull vNULL; > +static constexpr vnull vNULL{ }; > > Making vNULL have static linkage can make it an ODR violation to use > vNULL in templates and inline functions, because different > instantiations will refer to a different "vNULL" in each translation > unit. The ODR says this is OK because it's a literal constant with the same value (6.2/12.2.1). But it would be better without the explicit 'static'; then in C++17 it's implicitly inline instead of static. But then, do we really want to keep vNULL at all? It's a weird blurring of the object/pointer boundary that is also dependent on vec being a thin wrapper around a pointer. In almost all cases it can be replaced with {}; one exception is == comparison, where it seems to be testing that the embedded pointer is null, which is a weird thing to want to test. Somewhat relatedly, use of vec variables or fields seems almost always a mistake, as they need explicit .release() that could be automatic with auto_vec, and is easy to forget. For instance, the recursive call in get_all_loop_exits returns a vec that is never released. And I see a couple of leaks in the C++ front end as well. Jason