From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 502213858436 for ; Fri, 11 Nov 2022 18:58:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 502213858436 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x533.google.com with SMTP id 78so5036619pgb.13 for ; Fri, 11 Nov 2022 10:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VJUCo722gqMnJnPyV1vT2oDQ0NssIyjba5ySns+mzNA=; b=kiMFYWD96ySOke/PcIbMNJB75SMgf0wMfVyZ7/rUM5HGYHV5+NzEfjZv9duQgZiZ7N 8IRiHU5lb4+TC0ublk/UETCAGik8Ry2fgsJLW5CN1GAaxoQa6Ty+Mx/9jRv+NUccLND4 yeq+E6vc4lpoyGGYvVHlK55Yfgot+vY6PMPMkJiaYRaiC2pweHhKgUXfN7rRONhJZf80 gy5SInakwJlNURmjm7bF2yQF4WJ0/eWWCJ67ChefNH76aH1aSuAWAHdSx3Eb02aO5Ag4 sSGdGpI+M3mR3scXIveWGoYG7MjZ4/E0QFtXQe5VCNP+AA3/0Bem2YJSPiDU832AUOws 07nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VJUCo722gqMnJnPyV1vT2oDQ0NssIyjba5ySns+mzNA=; b=LsSW4p/XxZPznQsyVL4WewZBpzfBaMAGQTWNZPocCJt0nP7BfRC1eKFnTEW7LJIbDC DA1Lgf89WEwrSbC1MSSjX4IrMSoWmHlm5ZJ9gAyvjUbv1TT0dv2WOekRA3xR8cnmjial v1idRetnjTxqI7eMAaIidM6d1s25KG027bzwt06ZEpA/28KWy923K0O3JUC+kzy5kJWi yPaHx2R0RzF3rhkxrijtpfInJykNRby8/FR2Ne5041HTRfH6aNWaUYU7b14yv/EC3bGN Ud9NRksQGcH2BeLNUapA6H9WoCXI2v9BcJhGS960FWZbNZFMyw+5T7/MgSqSEDJnPV6G JnJw== X-Gm-Message-State: ANoB5pkqDYPvRR5zgnyCPxnzYVNTHg1EvR9rIepf9x3AMW1audZb2MWz V/ouvnXtuJY4xQ4pRbYpF04YgmBNWmtKCNpWDKs= X-Google-Smtp-Source: AA0mqf4f6y6uZHl3SKLleqFOhd2OzeoHVuHdM9E54EpKPs1hOVb5/reXLIBgnYsU53/Sa7UOAHb2B5X9tT3oDZF6+1c= X-Received: by 2002:a63:5265:0:b0:46f:b030:4011 with SMTP id s37-20020a635265000000b0046fb0304011mr2872358pgl.277.1668193124130; Fri, 11 Nov 2022 10:58:44 -0800 (PST) MIME-Version: 1.0 References: <20221111184759.2531849-1-ppalka@redhat.com> In-Reply-To: <20221111184759.2531849-1-ppalka@redhat.com> From: Andrew Pinski Date: Fri, 11 Nov 2022 10:58:31 -0800 Message-ID: Subject: Re: [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638] To: Patrick Palka Cc: gcc-patches@gcc.gnu.org, jason@redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Nov 11, 2022 at 10:48 AM Patrick Palka via Gcc-patches wrote: > > The commit r13-3706-gd0a492faa6478c for correcting the result of > __has_attribute(init_priority) causes a bootstrap failure on hppa64-hpux > because it assumes SUPPORTS_INIT_PRIORITY expands to a simple constant, > but on this target SUPPORTS_INIT_PRIORITY is defined as > > #define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0) > > (where TARGET_GNU_LD expands to something in terms of global_options) > which means we can't use this macro to statically exclude the entry > for init_priority when defining the cxx_attribute_table. > > So instead of trying to exclude init_priority from the attribute table > for sake of __has_attribute, this patch just makes __has_attribute > handle init_priority specially. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? Also sanity checked by artificially defining SUPPORTS_INIT_PRIORITY > to 0. > > PR c++/107638 > > gcc/c-family/ChangeLog: > > * c-lex.cc (c_common_has_attribute): Return 1 for init_priority > iff SUPPORTS_INIT_PRIORITY. > > gcc/cp/ChangeLog: > > * tree.cc (cxx_attribute_table): Don't conditionally exclude > the init_priority entry. > (handle_init_priority_attribute): Remove ATTRIBUTE_UNUSED. > Return error_mark_node if !SUPPORTS_INIT_PRIORITY. > --- > gcc/c-family/c-lex.cc | 9 +++++++++ > gcc/cp/tree.cc | 11 +++++++---- > 2 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc > index 89c65aca28a..2fe562c7ccf 100644 > --- a/gcc/c-family/c-lex.cc > +++ b/gcc/c-family/c-lex.cc > @@ -380,6 +380,15 @@ c_common_has_attribute (cpp_reader *pfile, bool std_syntax) > result = 201907; > else if (is_attribute_p ("assume", attr_name)) > result = 202207; > + else if (is_attribute_p ("init_priority", attr_name)) > + { > + /* The (non-standard) init_priority attribute is always > + included in the attribute table, but we don't want to > + advertise the attribute unless the target actually > + supports init priorities. */ > + result = SUPPORTS_INIT_PRIORITY ? 1 : 0; > + attr_name = NULL_TREE; > + } > } > else > { > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc > index c30bbeb0839..2324c2269fc 100644 > --- a/gcc/cp/tree.cc > +++ b/gcc/cp/tree.cc > @@ -5010,10 +5010,8 @@ const struct attribute_spec cxx_attribute_table[] = > { > /* { name, min_len, max_len, decl_req, type_req, fn_type_req, > affects_type_identity, handler, exclude } */ > -#if SUPPORTS_INIT_PRIORITY > { "init_priority", 1, 1, true, false, false, false, > handle_init_priority_attribute, NULL }, > -#endif Hmm, seems like this could be better handled if attribute_spec has another field which takes a function which returns if it is supported or not. And maybe remove some of the special cases inside c_common_has_attribute. I suspect there are some target ones which need special casing in more fancy way. An example of this is arm_handle_cmse_nonsecure_entry in config/arm/arm.cc . Where this attribute is not supported unless you use -mcmse option. Seems would be use if you want to use __has_attribute on cmse_nonsecure_entry to get the right value there too. Note I am not blocking this patch for this but just thinking out loud of how to improve this so special casing is not needed. Thanks, Andrew Pinski > { "abi_tag", 1, -1, false, false, false, true, > handle_abi_tag_attribute, NULL }, > { NULL, 0, 0, false, false, false, false, NULL, NULL } > @@ -5041,13 +5039,19 @@ const struct attribute_spec std_attribute_table[] = > > /* Handle an "init_priority" attribute; arguments as in > struct attribute_spec.handler. */ > -ATTRIBUTE_UNUSED static tree > +static tree > handle_init_priority_attribute (tree* node, > tree name, > tree args, > int /*flags*/, > bool* no_add_attrs) > { > + if (!SUPPORTS_INIT_PRIORITY) > + /* Treat init_priority as an unrecognized attribute (mirroring the > + result of __has_attribute) if the target doesn't support init > + priorities. */ > + return error_mark_node; > + > tree initp_expr = TREE_VALUE (args); > tree decl = *node; > tree type = TREE_TYPE (decl); > @@ -5105,7 +5109,6 @@ handle_init_priority_attribute (tree* node, > pri); > } > > - gcc_assert (SUPPORTS_INIT_PRIORITY); > SET_DECL_INIT_PRIORITY (decl, pri); > DECL_HAS_INIT_PRIORITY_P (decl) = 1; > return NULL_TREE; > -- > 2.38.1.420.g319605f8f0 >