From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout2.gsi.de (lxmtout2.gsi.de [140.181.3.112]) by sourceware.org (Postfix) with ESMTPS id 92BC53846079; Tue, 1 Jun 2021 21:01:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92BC53846079 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 lxmtout2.gsi.de (Postfix) with ESMTP id 08676202AD72; Tue, 1 Jun 2021 23:01:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout2.gsi.de Received: from lxmtout2.gsi.de ([127.0.0.1]) by localhost (lxmtout2.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oSHP_UjD8zYK; Tue, 1 Jun 2021 23:01:44 +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 lxmtout2.gsi.de (Postfix) with ESMTPS id E020C202AD64; Tue, 1 Jun 2021 23:01:44 +0200 (CEST) Received: from excalibur.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, 1 Jun 2021 23:01:44 +0200 From: Matthias Kretz To: , Jason Merrill CC: , David Malcolm , Jonathan Wakely Subject: Re: [PATCH] Add gnu::diagnose_as attribute Date: Tue, 1 Jun 2021 23:01:44 +0200 Message-ID: <3673050.7O1Wp1SQZX@excalibur> Organization: GSI Helmholtzzentrum =?UTF-8?B?ZsO8cg==?= Schwerionenforschung In-Reply-To: References: <14205410.xuKvIAzr1H@excalibur> <14231752.kytX9F1ty5@excalibur> 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: srvex1.Campus.gsi.de (10.10.4.11) To srvex3.campus.gsi.de (10.10.4.16) X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, SPF_PASS, TXREP, T_SPF_HELO_PERMERROR, URIBL_SBL, URIBL_SBL_A autolearn=no 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 21:01:48 -0000 On Tuesday, 1 June 2021 21:12:18 CEST Jason Merrill wrote: > On 5/28/21 3:42 AM, Matthias Kretz wrote: > > On Friday, 28 May 2021 05:05:52 CEST Jason Merrill wrote: > >> I'd think you could get the same effect from a hypothetical > >>=20 > >> namespace [[gnu::diagnose_as]] stdx =3D std::experimental; > >>=20 > >> though we'll need to add support for attributes on namespace aliases to > >> the grammar. > >=20 > > Right, but then two of my design goals can't be met: > >=20 > > 1. Diagnostics have an improved signal-to-noise ratio out of the box. > >=20 > > 2. We can use replacement names that are not valid identifiers. >=20 > This is the basic disconnect: I think that these goals are > contradictory, and that replacement names that are not valid identifiers > will just confuse users that don't know about them. With signal-to-noise ratio I meant the ratio (averaged over all GCC users -= so=20 yes, we can't give actual numbers for these): #characters one needs to read to understand / #total diagnostic character= s. Or more specifically 1 - #characters that are distracting from understanding the issue / #tota= l=20 diagnostic characters. Consider that for the stdx::simd case I regularly hit the problem that vim'= s=20 QuickFix truncates at 4095 characters and the message basically just got=20 started (i.e. it's sometimes impossible to use vim's QuickFix to understand= =20 errors involving stdx::simd). There's *a lot* of noise that must be removed= =20 *per default*. WRT "invalid identifiers", there are two types: (1) string of characters that is not a valid C++ identifier (2) valid C++ identifier, but not defined for the given TU (2) can be confusing, I agree, but doesn't have to be. (1) provides a stron= ger=20 hint that something is either abbreviated or intentionally hidden from the= =20 user. If I write `std::experimental::simd` in my code and get a diagnostic= =20 that says 'std=E2=82=93::simd' then it's relatively= easy to=20 make the connection what happened here: 'std=E2=82=93' clearly must mean so= mething=20 else than a literal 'std=E2=82=93' in my code. The user knows there's no `s= td::simd'=20 so it must be `std::experimental::simd`. (Note that once=20 std::experimental::simd goes into the IS, I would be the first to propose a= =20 change for 'std=E2=82=93::simd' back to 'std::experimental::simd'.) > If a user sees stdx::foo in a diagnostic and then tries to refer to > stdx::foo and gets an error, the diagnostic is not more helpful than one > that uses the fully qualified name. Hmm, if GCC prints an actual suggestion like "write 'std=E2=82=93::foo' her= e" then=20 yes, I agree. That should not make use of diagnose_as. > Jonathan, David, any thoughts on this issue? > > > I can imagine using it to make _Internal __names more readable while at > > the > > same time discouraging users to utter them in their own code. Sorry for > > the > > bad code obfuscation example above. > >=20 > > An example for consideration from stdx::simd: > > namespace std { > > namespace experimental { > > namespace parallelism_v2 [[gnu::diagnose_as("stdx")]] { > > namespace simd_abi [[gnu::diagnose_as("simd_abi")]] { > > =20 > > template > > =20 > > struct _VecBuiltin; > > =20 > > template > > =20 > > struct _VecBltnBtmsk; > > =20 > > #if x86 > > =20 > > using __ignore_me_0 [[gnu::diagnose_as("[SSE]")]] =3D _VecBuiltin<= 16>; > > using __ignore_me_1 [[gnu::diagnose_as("[AVX]")]] =3D _VecBuiltin<= 32>; > > using __ignore_me_2 [[gnu::diagnose_as("[AVX512]")]] =3D > > _VecBltnBtmsk<64>; > > =20 > > #endif > > }}}} > >=20 > > Then diagnostics would print 'stdx::simd' > > instead of 'stdx::simd>'. (Users utt= er > > the type by saying e.g. 'stdx::native_simd', while compiling with > > AVX512 flags.) > > Wouldn't it be better to print stdx::native_simd if that's how > the users write the type? No. For example, I might expect that native_simd maps to AVX-512 vectors bu= t=20 forgot the relevant -m flag(s). If the diagnostics show 'simd' I have a good chance of catching that issue. And the other way around: If I wrote `stdx::simd` and it happens to = be=20 the same type as the native_simd typedef, it would show the latter in=20 diagnostics. Similar issue with asking for a simd ABI with=20 `simd_abi::deduce_t`: I typically don't want to know whether tha= t's=20 also native_simd but rather what exact simd_abi I got. And no, as a= =20 user I don't typically care about the libstdc++ implementation details but= =20 what those details mean. =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