On Thu, 21 Aug 2025, David Faust wrote:
> Hi Joseph,
>
> On 8/20/25 15:49, Joseph Myers wrote:
> > On Tue, 12 Aug 2025, David Faust wrote:
> >
> >> + if (TREE_CODE (*node) == FUNCTION_TYPE || TREE_CODE (*node) ==
> >> METHOD_TYPE)
> >> + {
> >> + /* Treat btf_type_tag applied to a function type as applying to the
> >> + return type instead. Otherwise with GNU syntax there is no way to
> >> + apply type_tag to the return type; the parser always associates it
> >> + to the function_type node. btf_decl_tag can (should) be used to
> >> + annotate the function itself. */
> >> + tree ret_type = TREE_TYPE (*node);
> >> + tree new_attrs = tree_cons (name, args, TYPE_ATTRIBUTES (ret_type));
> >> + tree new_type = build_type_attribute_qual_variant (ret_type,
> >> + new_attrs,
> >> + TYPE_QUALS (ret_type));
> >> + TREE_TYPE (*node) = new_type;
> >
> > Is there some reason it's impossible for the function type here to be in
> > use for any other declaration? If not, modifying the return type of the
> > existing function type in-place like this seems unsafe.
> >
>
> No, I suppose there is no such reason. Do you mean that I need to use
> reconstruct_complex_type langhook here similar to the vector_size attribute
> handler? Or do you know some better/"more proper" way to solve this problem?
Something like that or equivalent - build a new function type with the
return type you've constructed (but the same parameters as before), rather
than modifying the function type in place. (If you want to support this
feature rather than requiring C23 syntax to get this particular
appertainment.)
--
Joseph S. Myers
josmy...@redhat.com
