From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id 86344386EC3F for ; Tue, 1 Jun 2021 19:56:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 86344386EC3F Received: by mail-ot1-x329.google.com with SMTP id d25-20020a0568300459b02902f886f7dd43so420062otc.6 for ; Tue, 01 Jun 2021 12:56:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mTw6N3ijyaTgkIw6B3GqB4YYnrz06uAMIRyTsJZnFV8=; b=kRLg9Kkd1ACSbbEnHLyAAMGknwi+b61bgVu5bV5fYzR0ItWkIYp2/k6h55cKWizJ68 vtQ+q3o628MF2M1X07bI7CGveVRvMWp52w57VaGdYSEHprUCmc94wSX8oyeyr7SI8psL sDXYD61RNSCrS8Vw5kljrddlWJ1/hnV9Z4A44LxIyLy/JJBbJ0tLHV1aQy+fZbXlouPY Xw+w/v2oHwORpSjo9P2BIFXCokxmd58IWoY8rk4G9gzcJUIoQG4PP6bKhNhY8zEIB7A4 JlIYfix+7SgNLCYO4pcC8tLTueOGwxCZlC3Sdigv/al6nKxRd7jUjSrVoyqyjlKwTliM 2cpg== X-Gm-Message-State: AOAM531Ff7Ly7PYRVNQFR4eyQmVE/V36TGt+0ta/SW1joTKKOP9BTLmg MTJkYdC2twlesmg5tqv7C3c= X-Google-Smtp-Source: ABdhPJw6pAzm58n291ElBR5Tfc/tH/HG4arEsUn7bAfiJnDfxoNYsnqWWDQReIGVzcvtzr6jNF0Ysw== X-Received: by 2002:a9d:799a:: with SMTP id h26mr1559172otm.49.1622577381893; Tue, 01 Jun 2021 12:56:21 -0700 (PDT) Received: from [192.168.0.41] (184-96-226-253.hlrn.qwest.net. [184.96.226.253]) by smtp.gmail.com with ESMTPSA id y7sm3938235oto.60.2021.06.01.12.56.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Jun 2021 12:56:21 -0700 (PDT) From: Martin Sebor Subject: Re: [PATCH] define auto_vec copy ctor and assignment (PR 90904) To: Jason Merrill , Richard Biener Cc: gcc-patches , Jonathan Wakely References: <91545a73-12af-33b2-c6e7-119b5a21de60@gmail.com> <4d503394-4e82-1d36-41ca-34315042775b@redhat.com> Message-ID: Date: Tue, 1 Jun 2021 13:56:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <4d503394-4e82-1d36-41ca-34315042775b@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 01 Jun 2021 19:56:24 -0000 On 5/27/21 2:53 PM, Jason Merrill wrote: > On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote: >> On 4/27/21 8:04 AM, Richard Biener wrote: >>> On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote: >>>> >>>> On 4/27/21 1:58 AM, Richard Biener wrote: >>>>> On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches >>>>> wrote: >>>>>> >>>>>> PR 90904 notes that auto_vec is unsafe to copy and assign because >>>>>> the class manages its own memory but doesn't define (or delete) >>>>>> either special function.  Since I first ran into the problem, >>>>>> auto_vec has grown a move ctor and move assignment from >>>>>> a dynamically-allocated vec but still no copy ctor or copy >>>>>> assignment operator. >>>>>> >>>>>> The attached patch adds the two special functions to auto_vec along >>>>>> with a few simple tests.  It makes auto_vec safe to use in containers >>>>>> that expect copyable and assignable element types and passes >>>>>> bootstrap >>>>>> and regression testing on x86_64-linux. >>>>> >>>>> The question is whether we want such uses to appear since those >>>>> can be quite inefficient?  Thus the option is to delete those >>>>> operators? >>>> >>>> I would strongly prefer the generic vector class to have the properties >>>> expected of any other generic container: copyable and assignable.  If >>>> we also want another vector type with this restriction I suggest to add >>>> another "noncopyable" type and make that property explicit in its name. >>>> I can submit one in a followup patch if you think we need one. >>> >>> I'm not sure (and not strictly against the copy and assign).  Looking >>> around >>> I see that vec<> does not do deep copying.  Making auto_vec<> do it >>> might be surprising (I added the move capability to match how vec<> >>> is used - as "reference" to a vector) >> >> The vec base classes are special: they have no ctors at all (because >> of their use in unions).  That's something we might have to live with >> but it's not a model to follow in ordinary containers. > > I don't think we have to live with it anymore, now that we're writing > C++11. > >> The auto_vec class was introduced to fill the need for a conventional >> sequence container with a ctor and dtor.  The missing copy ctor and >> assignment operators were an oversight, not a deliberate feature. >> This change fixes that oversight. >> >> The revised patch also adds a copy ctor/assignment to the auto_vec >> primary template (that's also missing it).  In addition, it adds >> a new class called auto_vec_ncopy that disables copying and >> assignment as you prefer. > > Hmm, adding another class doesn't really help with the confusion richi > mentions.  And many uses of auto_vec will pass them as vec, which will > still do a shallow copy.  I think it's probably better to disable the > copy special members for auto_vec until we fix vec<>. There are at least a couple of problems that get in the way of fixing all of vec to act like a well-behaved C++ container: 1) The embedded vec has a trailing "flexible" array member with its instances having different size. They're initialized by memset and copied by memcpy. The class can't have copy ctors or assignments but it should disable/delete them instead. 2) The heap-based vec is used throughout GCC with the assumption of shallow copy semantics (not just as function arguments but also as members of other such POD classes). This can be changed by providing copy and move ctors and assignment operators for it, and also for some of the classes in which it's a member and that are used with the same assumption. 3) The heap-based vec::block_remove() assumes its elements are PODs. That breaks in VEC_ORDERED_REMOVE_IF (used in gcc/dwarf2cfi.c:2862 and tree-vect-patterns.c). I took a stab at both and while (1) is easy, (2) is shaping up to be a big and tricky project. Tricky because it involves using std::move in places where what's moved is subsequently still used. I can keep plugging away at it but it won't change the fact that the embedded and heap-based vecs have different requirements. It doesn't seem to me that having a safely copyable auto_vec needs to be put on hold until the rats nest above is untangled. It won't make anything worse than it is. (I have a project that depends on a sane auto_vec working). A couple of alternatives to solving this are to use std::vector or write an equivalent vector class just for GCC. Martin > > Jason >