From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 233313858D28 for ; Mon, 17 Jul 2023 14:06:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 233313858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDA1BC15; Mon, 17 Jul 2023 07:07:12 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B24C23F738; Mon, 17 Jul 2023 07:06:28 -0700 (PDT) From: Richard Sandiford To: Jason Merrill Mail-Followup-To: Jason Merrill ,Jakub Jelinek , gcc-patches@gcc.gnu.org, joseph@codesourcery.com, polacek@redhat.com, nathan@acm.org, richard.sandiford@arm.com Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, joseph@codesourcery.com, polacek@redhat.com, nathan@acm.org Subject: Re: [WIP RFC] Add support for keyword-based attributes References: Date: Mon, 17 Jul 2023 15:06:27 +0100 In-Reply-To: (Jason Merrill's message of "Mon, 17 Jul 2023 09:39:49 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-20.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jason Merrill writes: > On Sun, Jul 16, 2023 at 6:50=E2=80=AFAM Richard Sandiford > wrote: > >> Jakub Jelinek writes: >> > On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via >> Gcc-patches wrote: >> >> Summary: We'd like to be able to specify some attributes using >> >> keywords, rather than the traditional __attribute__ or [[...]] >> >> syntax. Would that be OK? >> > >> > Will defer to C/C++ maintainers, but as you mentioned, there are many >> > attributes which really can't be ignored and change behavior >> significantly. >> > vector_size is one of those, mode attribute another, >> > no_unique_address another one (changes ABI in various cases), >> > the OpenMP attributes (omp::directive, omp::sequence) can change >> > behavior if -fopenmp, etc. >> > One can easily error with >> > #ifdef __has_cpp_attribute >> > #if !__has_cpp_attribute (arm::whatever) >> > #error arm::whatever attribute unsupported >> > #endif >> > #else >> > #error __has_cpp_attribute unsupported >> > #endif >> >> Yeah. It's easy to detect whether a particular ACLE feature is supporte= d, >> since there are predefined macros for each one. But IMO it's a failing >> if we have to recommend that any compilation that uses arm::foo should >> also have: >> >> #ifndef __ARM_FEATURE_FOO >> #error arm::foo not supported >> #endif >> >> It ought to be the compiler's job to diagnose its limitations, rather >> than the user's. >> >> The feature macros are more for conditional usage of features, where >> there's a fallback available. >> >> I suppose we could say that users have to include a particular header >> file before using an attribute, and use a pragma in that header file to >> tell the compiler to enable the attribute. But then there would need to >> be a separate header file for each distinct set of attributes (in terms >> of historical timeline), which would get ugly. I'm not sure that it's >> better than using keywords, or even whether it's better than predefining >> the "keyword" as a macro that expands to a compiler-internal attribute. >> > > With a combination of those approaches it can be a single header: > > #ifdef __ARM_FEATURE_FOO > #define __arm_foo [[arm::foo]] > // else use of __arm_foo will fail > #endif If we did that, would it be a defined part of the interface that __arm_foo expands to exactly arm::foo, rather than to an obfuscated or compiler-dependent attribute? In other words, would it be a case of providing both the attribute and the macro, and leaving users to choose whether they use the attribute directly (and run the risk of miscompilation) or whether they use the macros, based on their risk appetite? If so, the risk of miscompliation is mostly borne by the people who build the deployed code rather than the people who initially wrote it. If instead we say that the expansion of the macros is compiler-dependent and that the macros must always be used, then I'm not sure the header file provides a better interface than predefining the macros in the compiler (which was the fallback option if the keywords were rejected). But the diagnostics using these macros would be worse than diagnostics based on keywords, not least because the diagnostics about invalid use of the macros (from compilers that understood them) would refer to the underlying attribute rather than the macro. Thanks, Richard