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 282B63858C5E for ; Sun, 16 Jul 2023 10:50:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 282B63858C5E 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 868281042; Sun, 16 Jul 2023 03:51:36 -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 D2D773F740; Sun, 16 Jul 2023 03:50:52 -0700 (PDT) From: Richard Sandiford To: Jakub Jelinek Mail-Followup-To: Jakub Jelinek ,gcc-patches@gcc.gnu.org, joseph@codesourcery.com, polacek@redhat.com, jason@redhat.com, nathan@acm.org, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, joseph@codesourcery.com, polacek@redhat.com, jason@redhat.com, nathan@acm.org Subject: Re: [WIP RFC] Add support for keyword-based attributes References: Date: Sun, 16 Jul 2023 11:50:51 +0100 In-Reply-To: (Jakub Jelinek's message of "Fri, 14 Jul 2023 19:17:36 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-20.8 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: 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 supported, 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. Thanks, Richard