On Thu, Jun 18, 2026 at 05:31:34PM -0400, Marek Polacek wrote:
> On Thu, Jun 18, 2026 at 11:15:03PM +0200, Jakub Jelinek wrote:
> > On Thu, Jun 18, 2026 at 04:37:44PM -0400, Jason Merrill wrote:
> > > On 6/18/26 3:20 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/16?
> > > >
> > > > -- >8 --
> > > > Currently, we include all the built-ins like __builtin_fdimf32x in
> > > > the result of members_of. We probably should skip them. This patch
> > > > uses DECL_IS_UNDECLARED_BUILTIN so that we skip __builtin_abs but
> > > > include abs.
> > > >
> > > > On ^^:: this reduces the # of elements from 2591 to 653.
> > > >
> > > > PR c++/125819
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > * reflect.cc (namespace_members_of): Skip
> > > > DECL_IS_UNDECLARED_BUILTIN functions.
> > >
> > > Why only functions? I'd think we want to skip all kinds of built-in
> > > decls.
> >
> > I think it would be weird if builtins are hidden from members_of (sure, the
> > __integer_pack can be an exception), users can use say
> > decltype (::__builtin_fdimf32x) etc. too, so why should we hide them from
> > users during reflection through which they can query them similarly?
>
> I guess whatever we decide is OK from the standard POV. I just don't see
> much use for things like ^^__builtin_abs when one can do ^^abs. But I don't
> insist on getting this patch in at all.
To expand on this, I think we have various kinds of builtins.
The most common are builtins which aren't type-generic and have non-deduced
return type as well, I don't think there are any issues with those (example
__builtin_memset).
Then we have type-generic builtins with non-deduced return type (e.g.
__builtin_popcountg), those are usually implemented as vararg functions,
sometimes with one or more arguments before ..., sometimes with just ...
I think it isn't a big deal that we present them to users as vararg
functions, decltype on the __builtin_* has been providing that for years.
Another case are builtins where we deduce the return type to some particular
one, but only when it is used. Examples are __builtin_source_location,
__builtin_current_exception, where we change the return type from auto to
something different when they are first folded or evaluated. For this
category I think the best is not to list them in members_of (^^::, ...)
if they have still undeduced return type. Or force them to have the
return type deduced (the late deduction is done because we need
<source_location> or <exception> headers to be included, but guess
both are included by <meta> already and using members_of without meta
is invalid.
Then __integer_pack, I think you've handled that already.
And then there are type-generic builtins where the return value depends on
the arguments (e.g. __builtin_convertvector, __builtin_shuffle,
__builtin_bswapg, ...). Those are usually implemented as FE keywords and
don't appear in name-lookup, so not listing those is IMHO fine and nothing
special is needed for that.
Jakub
