From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id F06493858D32 for ; Mon, 29 Aug 2022 10:27:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F06493858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id A4C4F1F86C; Mon, 29 Aug 2022 10:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1661768830; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jrpUVdkwXtqU5wOIlB6C0t7rGF6qHzow/HJFC26cp54=; b=l55KodTQRnxOcBKikaZwwonjRYV8N7Cg+sdMxPK+QSJpNWJdw7hpkVoD1+w5j7kJaOvVJq 3uHqW7czBsqPGHv/vHV9THzUgnX2r29tRUy1NmVeqi8ehNb4o/NoqukKth0MOv2spH3dbd QgMJ9T3oqRkEvNXgWZ1YnQW+LdXNJSY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1661768830; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jrpUVdkwXtqU5wOIlB6C0t7rGF6qHzow/HJFC26cp54=; b=OYdNkrZsWMUrFrx29668n6nEqJ7GqgXBuS8cWcxOGWytobs1Z2f4ZPUn8eV+geSdbSEf3g 2xYjlLLU57prfJBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 920DD133A6; Mon, 29 Aug 2022 10:27:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id JgaeI36UDGN4RAAAMHmgww (envelope-from ); Mon, 29 Aug 2022 10:27:10 +0000 From: Martin Jambor To: Richard Biener Cc: GCC Patches , Richard Sandiford Subject: Re: [PATCH 1/2] vec: Add array_slice constructors from non-const and gc vectors In-Reply-To: References: User-Agent: Notmuch/0.35 (https://notmuchmail.org) Emacs/28.1 (x86_64-suse-linux-gnu) Date: Mon, 29 Aug 2022 12:27:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi again, On Mon, Aug 29 2022, Richard Biener wrote: > On Fri, 26 Aug 2022, Martin Jambor wrote: > >> Hi, >>=20 >> On Fri, Aug 26 2022, Richard Biener wrote: >> >> Am 26.08.2022 um 18:39 schrieb Martin Jambor : >> >> >> >> =EF=BB=BFHi, >> >> >> >> This patch adds constructors of array_slice that are required to >> >> create them from non-const (heap or auto) vectors or from GC vectors. >> >> >> >> The use of non-const array_slices is somewhat limited, as creating one >> >> from const vec still leads to array_slice, >> >> so I eventually also only resorted to having read-only array_slices. >> >> But I do need the constructor from the gc vector. >> >> >> >> Bootstrapped and tested along code that actually uses it on >> >> x86_64-linux. OK for trunk? >> >> >> >> Thanks, >> >> >> >> Martin >> >> >> >> >> >> gcc/ChangeLog: >> >> >> >> 2022-08-08 Martin Jambor >> >> >> >> * vec.h (array_slice): Add constructors for non-const reference to >> >> heap vector and pointers to heap vectors. >> >> --- >> >> gcc/vec.h | 12 ++++++++++++ >> >> 1 file changed, 12 insertions(+) >> >> >> >> diff --git a/gcc/vec.h b/gcc/vec.h >> >> index eed075addc9..b0477e1044c 100644 >> >> --- a/gcc/vec.h >> >> +++ b/gcc/vec.h >> >> @@ -2264,6 +2264,18 @@ public: >> >> array_slice (const vec &v) >> >> : m_base (v.address ()), m_size (v.length ()) {} >> >> >> >> + template >> >> + array_slice (vec &v) >> >> + : m_base (v.address ()), m_size (v.length ()) {} >> >> + >> >> + template >> >> + array_slice (const vec *v) >> >> + : m_base (v ? v->address () : nullptr), m_size (v ? v->length ()= : 0) {} >> >> + >> >> + template >> >> + array_slice (vec *v) >> >> + : m_base (v ? v->address () : nullptr), m_size (v ? v->length ()= : 0) {} >> >> + >> > >> > I don?t quite understand why the generic ctor doesn?t cover the GC cas= e. It looks more like reference vs pointer? >> > >>=20 >> If you think that this should work: >>=20 >> vec *heh =3D cfun->local_decls; >> array_slice arr_slice (*heh); >>=20 >> then it does not: >>=20 >> /home/mjambor/gcc/mine/src/gcc/ipa-cp.cc:6693:36: error: no matching f= unction for call to ?array_slice::array_slice(vec&)? >> 6693 | array_slice arr_slice (*heh); >> | ^ >> In file included from /home/mjambor/gcc/mine/src/gcc/hash-table.h:248, >> from /home/mjambor/gcc/mine/src/gcc/coretypes.h:486, >> from /home/mjambor/gcc/mine/src/gcc/ipa-cp.cc:105: >> /home/mjambor/gcc/mine/src/gcc/vec.h:2264:3: note: candidate: ?templat= e array_slice::array_slice(const vec&) [with T =3D= tree_node*]? >> 2264 | array_slice (const vec &v) >> | ^~~~~~~~~~~ >> /home/mjambor/gcc/mine/src/gcc/vec.h:2264:3: note: template argument= deduction/substitution failed: >> /home/mjambor/gcc/mine/src/gcc/ipa-cp.cc:6693:36: note: mismatched t= ypes ?va_heap? and ?va_gc? >> 6693 | array_slice arr_slice (*heh); >> | ^ >>=20 >> [... I trimmed notes about all other candidates...] >>=20 >> Or did you mean something else? > > Hmm, so what if you change > > template > array_slice (const vec &v) > : m_base (v.address ()), m_size (v.length ()) {} > > to > > template > array_slice (const vec &v) > : m_base (v.address ()), m_size (v.length ()) {} > > instead? Thus allow any allocation / placement template arg? > So being fully awake helps, the issue was of course in how I tested the code, the above works fine and I can adapt my code to use that. However, is it really preferable? We often use NULL as to mean zero-length vector, which my code handled gracefully: + template + array_slice (const vec *v) + : m_base (v ? v->address () : nullptr), m_size (v ? v->length () : 0) = {} whereas using the generic method will mean that users constructing the vector will have to special case it - and I bet most will end up using the above sequence and the constructor from explicit pointer and size in all constructors from gc vectors. So, should I really change the patch and my code? Thanks, Martin