On Sat, Nov 29, 2025 at 06:37:03PM +0530, Jason Merrill wrote:
> > Unfortunately it is not. ATTR_ID here is just the attribute name, so
> > lookup_attribute_spec attempts to find it in the gnu namespace rather than
> > in the "internal " namespace in which it is present, and fails.
> >
> > In order to make it work I guess is_late_template_attribute would need to
> > pass
> > TREE_PURPOSE (attr) instead of name to attribute_takes_identifier_p,
> > similarly tsubst_attribute pass TREE_PURPOSE (t) instead of
> > get_attribute_name (t), and attribute_takes_identifier_p would then need
> > to do if (TREE_CODE (attr_id) == TREE_LIST) attr_id = TREE_VALUE (attr_id);
> > for the targetm.* call at the end (which still expects just IDENTIFIER_NODE.
> > Similarly maybe is_late_template_attribute should again call
> > lookup_attribute_spec on TREE_PURPOSE (attr) rather than name and then the
> > if (annotation_p (attr)) return true; stuff could be done after the
> > if (!spec) return false; checking.
>
> Sounds good, perhaps as a separate patch.
Ok, will do a separate patch for that.
> But the current behavior of merge_attributes reverses the order of the a2
> list while leaving the a1 list in the same order. This behavior seems too
> chaotic to be worth trying to preserve; keeping both lists in order seems
> strictly better.
Ok, will change.
> > So, shall it use attribute_value_equal instead?
>
> Yes, that seems like it would be an improvement, perhaps along with the
> is_late_template_attribute cleanup or by itself.
Ok, another incremental patch.
> > > Why does this need to loop?
> > >
> > > > + c = BINFO_INHERITANCE_CHAIN (c);
> >
> > The current patchset records direct base relationship reflection
> > as REFLECT_BASE with a TREE_BINFO as REFLECT_EXPR_HANDLE.
> > That looked to me best as it is an existing tree, instead of having
> > to create say a TREE_VEC with 2 elements or TREE_LIST, where one
> > operand of that would be the derived class and the other the base
> > class. The base class is immediately accessible from the TREE_BINFO,
> > it is BINFO_TYPE (REFLECT_EXPR_HANDLE (t)). The derived class is
> > usually BINFO_TYPE (BINFO_INHERITANCE_CHAIN (REFLECT_EXPR_HANDLE (t))),
> > but not always, sometimes there is longer BINFO_INHERITANCE_CHAIN
> > chain before reaching the final one (which has NULL
> > BINFO_INHERITANCE_CHAIN).
>
> Sure, I'm looking for a comment about when there can be a longer chain. Is
> it when a direct virtual base is a primary base of a non-virtual base?
E.g. g++.dg/reflect/bases_of2.C
struct A {};
struct B : virtual A {};
struct C : virtual A {};
struct D : virtual B, virtual C {};
struct E : virtual D {};
struct F : virtual D, virtual E {};
The (F, D) direct base relationship TREE_BINFO has
BINFO_INHERITANCE_CHAIN (BINFO_INHERITANCE_CHAIN (base_binfo)) non-NULL and
only BINFO_TYPE of that is F.
Jakub
