From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id AF90B3858C53 for ; Sun, 14 May 2023 16:05:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF90B3858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 7059 invoked from network); 14 May 2023 16:05:16 -0000 X-APM-Out-ID: 16840803160705 X-APM-Authkey: 257869/1(257869/1) 12 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 14 May 2023 16:05:16 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: [PATCH][RFC] c-family: Implement __has_feature and __has_extension [PR60512] From: Iain Sandoe In-Reply-To: Date: Sun, 14 May 2023 17:05:16 +0100 Cc: GCC Patches , Joseph Myers , Jason Merrill , Nathan Sidwell Content-Transfer-Encoding: quoted-printable Message-Id: <77197F1C-5183-4F12-8701-83ACFF5FC96F@sandoe.co.uk> References: To: Alex Coplan X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,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: Hi Alex, thanks for working on this. I=E2=80=99ve applied this patch and evaluated on a few Darwin versions = (which is the target currently most affected, I believe): > On 9 May 2023, at 13:07, Alex Coplan wrote: > This patch implements clang's __has_feature and __has_extension in = GCC. Thanks, this blocks consuming Darwin SDK headers =E2=80=9Cproperly=E2=80=9D= (PR 90709 as linked to 60512) (which is why I had a WIP patch too). So I am very keen to see this land in GCC-14, but have some issues to = deal=20 with and would be looking for ideas about how to handle them by = extending or amending the patch. The main concern I have at the moment is that it seems to me that we = need more flexible and general predicates for declaring feature/ext support: a) on target (see below for examples) b) on potentially multiple flags and language version at the same time = (see below) c) what about features that exist for a closed range of language = versions? As mentioned by Jakub in a conversation about this on irc (months ago!) = the current identifiers potentially clash with use symbols. IFF we add feature designations (which IMO we should, since this = approach does help simplify testcases and configurations) we should add them into the implementation namespace: e.g. ( for C)=20 _GNU_nested_functions or __nested_functions > Currently the patch aims to implement all documented features (and = some > undocumented ones) following the documentation at > https://clang.llvm.org/docs/LanguageExtensions.html TL;DR=20 without guards or target-specific opt out this breaks bootstrap on = Darwin. I believe the patch is operating correctly .. but it is now exposing = problems in the system Frameworks that (in this first example) is union of three = bugs in the headers and clang versions. Darwin=E2=80=99s SDK headers are a pretty complex amalgamation of macro = and conditional code spanning both regular (i.e. /usr/include) style headers = and those found in frameworks. This took a bit of tracking down. The bootstrap fail occurs because (with the patch) we now invoke a macro CF_ENUM in the CoreFoundation framework with extended args. BUG1; This macro expands to wrong code (AFAICT) for a typedef enum.=20 BUG2; However, Apple clang accepts the wrong code and treats it as = typedef. (GCC and upstream clang both reject, although MSVC accepts) BUG3: Upstream clang is disabling that error when it appears in system = headers. .. so that combination means that we have a broken core framework header = that went undetected by both Apple and upstream clang. Now it is possible that the header could be fixed in some future edition = of the SDK. However that does not help existing and previous SDKs (I do not = recall a fix ever being made of any SDK other than the current). So I have to = figure out how to approach this. 1. We could =E2=80=98fixincludes=E2=80=99 the issues=E2=80=A6 except = because of PR105719, we can=E2=80=99t because we do not have fixincludes for frameworks yet ... [this is not probably impossible to arrange but it=E2=80=99s quite = some work to make sure we interpose the fixes correctly] 2. We could allow specific targets to opt out of declaring that they = have support for some specific feature (see also below). (one reason to allow target opt-in/out of specific features) > with the following omissions: > - Objective-C-specific features. I can clearly append the objective-c(++) cases to the end of the = respective lists, but then we need to make them conditional on language, version = and dialect (some will not be appropriate to GNU runtime). this is why I think we need more flexible predicates on declaring = features and extensions. ---- index 2b4c82facf7..5b8429244b2 100644 --- a/gcc/c-family/c-common.cc +++ b/gcc/c-family/c-common.cc +struct hf_feature_info + { "enumerator_attributes", 0, 0 }, + { "tls", 0, 0 }, Do all GCC targets support tls? What about things like this: attribute_availability_tvos,=20 attribute_availability_watchos,=20 attribute_availability_driverkit,=20 ? Even if they are implemented centrally, it is unlikely that all targets = would want to claim support (although note that the availability stuff does seem = now to be used on other platforms - like android, zos and hlsl.) (non-bug-related reasons to consider target-specific predicates) =3D=3D=3D Once again, thanks for working on this - and I am keen to see it land, Iain