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 C38A2385502B for ; Fri, 18 Jun 2021 11:05:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C38A2385502B Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-555-wXYaQZpMNTGYW--nBaH6_g-1; Fri, 18 Jun 2021 07:05:00 -0400 X-MC-Unique: wXYaQZpMNTGYW--nBaH6_g-1 Received: by mail-wr1-f72.google.com with SMTP id x9-20020adfffc90000b02901178add5f60so4225354wrs.5 for ; Fri, 18 Jun 2021 04:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r0q8L60BvaY2kXy3cpPKTPlpKurP6LVCsSdf21EahAo=; b=Y40VoR+6bKrES8FDAkzrzebR81ZBKPSpPEBOu+RW7folBShNJtDnhb7jICuDkr3rgu 6vfclzS8O56q1qLXODu9nAmRz0nv2reJ7L/mbQpUEmdh1JBRVNzeM5s6Rg8Rwar/p5kO dqsvP6bQvMvVOPkxfh+vgpEkC9+X3p6Mq5WAQKB0x22g3oljyyjzkDQ1UbE7xaEdsRRO mBllhCy9i+KCgjrZDPQSfehE6V2EeRrBnQFj06ZufJYwMpNqIWtFpgJptsFcHRz/dYE7 P6gBNo/Jh4+k9TPKrjAheD8JJmEouAhnfiBlXXUoNI+xzs/uKEXPzQvzHQzrI8f20KUa 2Ohg== X-Gm-Message-State: AOAM531Hw4ha0KektbgVR++zTiGjmCfuNZPVz2HK/WxLDSEROIICUQYa 3/Y4A6tGYKZV///Xq8HJjq89rYzgZrkdrNiuADjl9q3x/armE9ffWovzvAQJ7GujMrOGYHswd2z WVl3p8pqhD/SBhnQM/sLSriTT45q6UcT9lw== X-Received: by 2002:a05:6000:cb:: with SMTP id q11mr11824908wrx.13.1624014299082; Fri, 18 Jun 2021 04:04:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyPkOXHZRGQBVZDMas3ka7NgbplWO+EU9QjEzsCuZ2WeVNktkdBKKy+fcNZ78UWqpxn9Pm1yc42n7h7/i+9kg= X-Received: by 2002:a05:6000:cb:: with SMTP id q11mr11824895wrx.13.1624014298974; Fri, 18 Jun 2021 04:04:58 -0700 (PDT) MIME-Version: 1.0 References: <20210615055922.27205-1-tbsaunde@tbsaunde.org> <20210615055922.27205-5-tbsaunde@tbsaunde.org> <9a54c5e1-2d41-f499-e176-84913b810b67@gmail.com> <125764da-111e-7e44-b2ba-8389644423e8@gmail.com> <20210618105354.GM7746@tucnak> In-Reply-To: From: Jonathan Wakely Date: Fri, 18 Jun 2021 12:04:48 +0100 Message-ID: Subject: Re: [PATCH 5/6] make get_domminated_by_region return a auto_vec To: Jakub Jelinek Cc: Richard Biener , Martin Sebor , Trevor Saunders , Richard Biener via Gcc-patches , Richard Sandiford X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Fri, 18 Jun 2021 11:05:05 -0000 On Fri, 18 Jun 2021 at 12:03, Jonathan Wakely wrote: > > On Fri, 18 Jun 2021 at 11:54, Jakub Jelinek wrote: > > > > On Fri, Jun 18, 2021 at 12:38:09PM +0200, Richard Biener via Gcc-patches wrote: > > > > Yes, as we discussed in the review below, vec is not a good model > > > > because (as you note again above) it's constrained by its legacy > > > > uses. The best I think we can do for it is to make it safer to > > > > use. > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571622.html > > > > > > Which is what Trevors patches do by simply disallowing things > > > that do not work at the moment. > > > > I only see > > // You probably don't want to copy a vector, so these are deleted to prevent > > // unintentional use. If you really need a copy of the vectors contents you > > // can use copy (). > > auto_vec(const auto_vec &) = delete; > > auto_vec &operator= (const auto_vec &) = delete; > > on the > > template > > class auto_vec : public vec > > specialization, but not on the > > template > > class auto_vec : public vec > > template itself. Shouldn't that one have also the deleted > > copy ctor/assignment operator and in addition to that maybe deleted > > move ctor/move assignment operator? > > That might have some value as documentation for people reading the > code, but it's not necessary. If vec has a deleted copy ctor and copy > assignment then it has no implicitly-defined move ctor and move > assignment. And the same goes for anything deriving from vec. Oh sorry, I misread the first snippet. So yes, it should probably be on both specializations. But deleting the moves is not necessary.