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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 1935E3857817 for ; Wed, 16 Jun 2021 00:48:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1935E3857817 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-496-xrAu7wekMXeDtGK13jKcYg-1; Tue, 15 Jun 2021 20:48:11 -0400 X-MC-Unique: xrAu7wekMXeDtGK13jKcYg-1 Received: by mail-qt1-f200.google.com with SMTP id 61-20020aed21430000b029024e7e455d67so451159qtc.16 for ; Tue, 15 Jun 2021 17:48:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CdC6ajZkkRuuwtbOsyUZcHE1OQ5YEtJst9lD/ioaHw0=; b=rx4CrU5cFd9o4fRo5xwbGvgM0b0cLeWmd1Ts+rrmGrzOo4sL0/gakPsQfowxVHCve9 wAH8KoP5Gxf7YWUgnqjAQhwHZ+29K69dy3Duxo5SfJsP4edJoaJHv2k6+rewMYENZ6vu BYxVsJqgSoWiAfDWt/o/M7IGoMYgBvH6c4tBieI3haZiQsuKRqhmgd4mtttPoqnTJLCJ QjtQzVPU96cRQbwlcYpkEXl1FpMabZtuamVYyINfNXno+FSAzkSKmQX7EaXpkwTFHsjW BmgVNU70K/TyJqdofglMmDNr/aqDiHkU667BRQ8XcmRnNlVSocBTwcEmqe6ugjr0JVp+ G04g== X-Gm-Message-State: AOAM532u5hICo/RS/XDrYcusxn2hOd6ewblngz6R+8+FIXerPVHb4JVY 3w30ZXxzYMvT0QeM9C2wMuHnnhtBTyNs+F3NKADszVpm4KNf3k3V+F/aKcEDl7nV2FGKFORX7u4 3FBf14X5M0rucLyI= X-Received: by 2002:a37:848:: with SMTP id 69mr2433983qki.411.1623804491076; Tue, 15 Jun 2021 17:48:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyH4YrfnpcFRAY3q2uO00VvENGk7MC0kAeSnzJ9G9j++JalQERGr3z3frcBcfv5kcFRYbVV6A== X-Received: by 2002:a37:848:: with SMTP id 69mr2433967qki.411.1623804490774; Tue, 15 Jun 2021 17:48:10 -0700 (PDT) Received: from [192.168.1.148] (130-44-159-43.s11817.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id e11sm555217qkl.28.2021.06.15.17.48.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 17:48:09 -0700 (PDT) Subject: Re: [PATCH] Add gnu::diagnose_as attribute To: Matthias Kretz , gcc-patches@gcc.gnu.org Cc: libstdc++@gcc.gnu.org, David Malcolm , Jonathan Wakely References: <14205410.xuKvIAzr1H@excalibur> <2132675.qKCeTcHjAi@excalibur> <9926a8f5-5513-11eb-75a2-ef405e14ff1a@redhat.com> <2511559.k3LOHGUjKi@minbar> From: Jason Merrill Message-ID: Date: Tue, 15 Jun 2021 20:48:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2511559.k3LOHGUjKi@minbar> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 00:48:14 -0000 On 6/15/21 4:56 PM, Matthias Kretz wrote: > 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. >>> >>> We could also talk about extending the feature to provide more information >>> 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". >> >> 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 the > end. > >>> -struct _Scalar; >>> + struct [[__gnu__::__diagnose_as__("scalar")]] _Scalar; >>> >>> template >>> >>> - struct _Fixed; >>> + struct [[__gnu__::__diagnose_as__("fixed_size")]] _Fixed; >> >> 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]")]] = _VecBuiltin<16>; >>> +using __avx [[__gnu__::__diagnose_as__("[AVX]")]] = _VecBuiltin<32>; >>> +using __avx512 [[__gnu__::__diagnose_as__("[AVX512]")]] = >>> _VecBltnBtmsk<64>; + using __odr_helper [[__gnu__::__diagnose_as__("[ODR >>> 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 them > to use in their code. We could argue "it has a double-underscore and it's not > a documented implementation-defined type, so you're shooting yourself in the > foot". Or we could just avoid the issue altogether. I agree this is not a huge > 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 above). > > Yes, with the following consequences: > > * If only the std::experimental::parallelism_v2::simd headers set the > diagnose_as attribute on std::experimental, the #inclusion of simd> changes the diagnostics of all other TS implementations. > > * If all TS implementations set the diagnose_as attribute, then it's basically > impossible to go back to the long and scary name. Which is what we really > should do as soon as there's both a std::simd and a stdₓ::simd. Attaching the > diagnose_as attribute to the inline namespace allows for better granularity, > even if it's maybe not good enough for some TSs. > > * If `namespace std { namespace experimental [[gnu::diagnose_as("foo")]] {` > turns the scope into 'foo::' and not 'std::foo::' (not sure what you intended) > 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 > 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 make > diagnostics worse, by replacing names with strings that are not valid > identifiers. Of course, whoever uses the attribute to that effect should have > a good reason to do so. Is your other concern that using the attribute in a > "good" way is repetitive? Would you be happier if I make the string argument > to the attribute optional for type aliases? Yes, and namespace aliases. Jason