https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #37 from Bill Wendling <isanbard at gmail dot com> ---
(In reply to Jakub Jelinek from comment #36)
> (In reply to Bill Wendling from comment #33)
> > __builtin_get_attr_arg (ptr, attr_name)
> >
> > This could have an optional argument to specify which argument to get if the
> > attr has more than one:
> >
> > __builtin_get_attr_arg (ptr, attr_name, pos)
>
> This is a bad idea. The first argument of counted_by attribute is an
> identifier, that isn't really useful for anything and how you'd return that?
> And for other attributes which do have arguments, what exactly the argument
> is is heavily dependent on the attribute and there is simply no way how to
> represent those easily.
> Consider
> [[omp::sequence (directive (parallel private (p)),
> omp::directive (single copyprivate (p) firstprivate (f) allocate (f)))]]
> or
> __attribute__((mode (DI)))
> or
> __attribute__((vector_size (16)))
> or
> __attribute__ ((__format__(__printf__, 1, 2)))
> or
> [[gnu::alias ("foobar")]]
> etc.
> What would be the argument of some of these attributes for the return of the
> builtin, what types it would have, ...?
I realized my error after sending this. So yeah it's not going to work. I'm
okay with what's being discussed. I just want to make it clear to the
programmer that it's _possible_ that the builtin may become a no-op and they
need to handle that, which will be DCE'ed if the attribute exists, etc.
That does make me wonder at the usefulness of this feature. The user will need
to set the count whether or not this builtin is used (either because
'counted_by' wasn't specified or the compiler couldn't find the COUNT variable
for some reason (a compiler bug, but still...)). Isn't that basically creating
a feature useful for only this specific use case?
