public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638]
@ 2022-11-11 18:47 Patrick Palka
  2022-11-11 18:58 ` Andrew Pinski
  2022-11-14 23:17 ` Jason Merrill
  0 siblings, 2 replies; 3+ messages in thread
From: Patrick Palka @ 2022-11-11 18:47 UTC (permalink / raw)
  To: gcc-patches; +Cc: jason, Patrick Palka

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
   { "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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638]
  2022-11-11 18:47 [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638] Patrick Palka
@ 2022-11-11 18:58 ` Andrew Pinski
  2022-11-14 23:17 ` Jason Merrill
  1 sibling, 0 replies; 3+ messages in thread
From: Andrew Pinski @ 2022-11-11 18:58 UTC (permalink / raw)
  To: Patrick Palka; +Cc: gcc-patches, jason

On Fri, Nov 11, 2022 at 10:48 AM Patrick Palka via Gcc-patches
<gcc-patches@gcc.gnu.org> 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
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638]
  2022-11-11 18:47 [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638] Patrick Palka
  2022-11-11 18:58 ` Andrew Pinski
@ 2022-11-14 23:17 ` Jason Merrill
  1 sibling, 0 replies; 3+ messages in thread
From: Jason Merrill @ 2022-11-14 23:17 UTC (permalink / raw)
  To: Patrick Palka, gcc-patches

On 11/11/22 08:47, Patrick Palka 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.

OK.

> 	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
>     { "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;


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-11-14 23:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-11 18:47 [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638] Patrick Palka
2022-11-11 18:58 ` Andrew Pinski
2022-11-14 23:17 ` Jason Merrill

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).