From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout1.gsi.de (lxmtout1.gsi.de [140.181.3.111]) by sourceware.org (Postfix) with ESMTPS id A920C3851C29; Tue, 15 Jun 2021 20:56:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A920C3851C29 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gsi.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gsi.de Received: from localhost (localhost [127.0.0.1]) by lxmtout1.gsi.de (Postfix) with ESMTP id 25E442050D08; Tue, 15 Jun 2021 22:56:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout1.gsi.de Received: from lxmtout1.gsi.de ([127.0.0.1]) by localhost (lxmtout1.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xp1tX-mo71HJ; Tue, 15 Jun 2021 22:56:21 +0200 (CEST) Received: from srvex3.campus.gsi.de (unknown [10.10.4.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by lxmtout1.gsi.de (Postfix) with ESMTPS id 0A9A32050D00; Tue, 15 Jun 2021 22:56:21 +0200 (CEST) Received: from minbar.localnet (140.181.3.12) by srvex3.campus.gsi.de (10.10.4.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.10; Tue, 15 Jun 2021 22:56:20 +0200 From: Matthias Kretz To: , Jason Merrill CC: , David Malcolm , Jonathan Wakely Subject: Re: [PATCH] Add gnu::diagnose_as attribute Date: Tue, 15 Jun 2021 22:56:20 +0200 Message-ID: <2511559.k3LOHGUjKi@minbar> Organization: GSI Helmholtz Centre for Heavy Ion Research In-Reply-To: <9926a8f5-5513-11eb-75a2-ef405e14ff1a@redhat.com> References: <14205410.xuKvIAzr1H@excalibur> <2132675.qKCeTcHjAi@excalibur> <9926a8f5-5513-11eb-75a2-ef405e14ff1a@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [140.181.3.12] X-ClientProxiedBy: SRVEX2.campus.gsi.de (10.10.4.15) To srvex3.campus.gsi.de (10.10.4.16) X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, SPF_HELO_PASS, 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, 15 Jun 2021 20:56:24 -0000 On Tuesday, 15 June 2021 17:51:20 CEST Jason Merrill wrote: > On 6/11/21 6:01 AM, Matthias Kretz wrote: > > For reference I'll attach my stdx::simd diagnose_as patch. > >=20 > > We could also talk about extending the feature to provide more informat= ion > > about the diagnose_as substition. E.g. print a list of all diagnose_as > > substitutions, which were used, at the end of the output stream. Or > > simpler, print "note: some identifiers were simplified, use > > -fno-diagnostics-use- aliases to see their real names". >=20 > Or perhaps before the first use of a name that doesn't correspond to a > source-level name. Right. I guess that would be even easier to implement than printing it at t= he=20 end. > > -struct _Scalar; > > + struct [[__gnu__::__diagnose_as__("scalar")]] _Scalar; > >=20 > > template > >=20 > > - struct _Fixed; > > + struct [[__gnu__::__diagnose_as__("fixed_size")]] _Fixed; >=20 > Thes two could be the variant of the attribute without an explicit > string, attached to the alias-declaration. Agreed. (since you don't have implementation concerns...) > > +using __sse [[__gnu__::__diagnose_as__("[SSE]")]] =3D _VecBuiltin<16>; > > +using __avx [[__gnu__::__diagnose_as__("[AVX]")]] =3D _VecBuiltin<32>; > > +using __avx512 [[__gnu__::__diagnose_as__("[AVX512]")]] =3D > > _VecBltnBtmsk<64>; + using __odr_helper [[__gnu__::__diagnose_as__("[O= DR > > helper]")]] > These [] names seem like minimal improvements over the __ names that you > would get from the attribute without an explicit string. Right. It would, however, give the user an identifier that I don't want the= m=20 to use in their code. We could argue "it has a double-underscore and it's n= ot=20 a documented implementation-defined type, so you're shooting yourself in th= e=20 foot". Or we could just avoid the issue altogether. I agree this is not a h= uge=20 issue. > > + inline namespace parallelism_v2 > > [[__gnu__::__diagnose_as__("std\u2093")]] { > This could go on std::experimental itself, along with my proposed change > to hide inline namespaces by default (with a note similar to the one abov= e). Yes, with the following consequences: * If only the std::experimental::parallelism_v2::simd headers set the=20 diagnose_as attribute on std::experimental, the #inclusion of changes the diagnostics of all other TS implementations. * If all TS implementations set the diagnose_as attribute, then it's basica= lly=20 impossible to go back to the long and scary name. Which is what we really=20 should do as soon as there's both a std::simd and a std=E2=82=93::simd. Att= aching the=20 diagnose_as attribute to the inline namespace allows for better granularity= ,=20 even if it's maybe not good enough for some TSs. * If `namespace std { namespace experimental [[gnu::diagnose_as("foo")]] {`= =20 turns the scope into 'foo::' and not 'std::foo::' (not sure what you intend= ed)=20 then I could still attach the attribute to the inline namespace. So, yes, I could improve stdx::simd with what you propose. IMHO it wouldn't= be=20 as good as what I can do with the patch at hand, though. IIUC, your main concern is that my proposed diagnose_as *can* be used to ma= ke=20 diagnostics worse, by replacing names with strings that are not valid=20 identifiers. Of course, whoever uses the attribute to that effect should ha= ve=20 a good reason to do so. Is your other concern that using the attribute in a= =20 "good" way is repetitive? Would you be happier if I make the string argumen= t=20 to the attribute optional for type aliases? =2D-=20 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de std::experimental::simd https://github.com/VcDevel/std-simd =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80