On Wed, Nov 26, 2025 at 09:49:45AM +0100, Richard Biener wrote:
> > --- gcc/cp/cp-objcp-common.cc.jj 2025-10-09 22:41:19.871273246 +0200
> > +++ gcc/cp/cp-objcp-common.cc 2025-11-25 12:37:38.251339146 +0100
> > @@ -181,10 +181,10 @@ cxx_get_alias_set (tree t)
> > return get_alias_set (TYPE_CONTEXT (t));
> >
> > /* Punt on PMFs until we canonicalize functions properly. */
> > - if (TYPE_PTRMEMFUNC_P (t)
> > - || (INDIRECT_TYPE_P (t)
> > - && TYPE_PTRMEMFUNC_P (TREE_TYPE (t))))
> > + if (TYPE_PTRMEMFUNC_P (t))
> > return 0;
> > + if (INDIRECT_TYPE_P (t) && TYPE_PTRMEMFUNC_P (TREE_TYPE (t)))
> > + return get_alias_set (ptr_type_node);
>
> I think we'd get the same effect from alias.cc itself iff
> TYPE_PTRMEMFUNC_P were TYPE_STRUCTURAL_EQUALITY_P. In particular
> I'll not that a PMF ** would not end up invoking the langhook for
> PMF *. While the pointer code in get_alias_set eventually
> looks at the "base", it does not re-query the frontend about it,
> but only special-case
>
> if (TREE_CODE (p) == VOID_TYPE || TYPE_STRUCTURAL_EQUALITY_P (p))
> set = get_alias_set (ptr_type_node);
>
> so given it seems we don't exactly know what goes wrong I fear while
> the fix makes sense, it's not complete? Unless TYPE_PTRMEMFUNC_P
> already is TYPE_STRUCTURAL_EQUALITY_P, in which case all the
> special-casing could go?
It is TYPE_STRUCTURAL_EQUALITY_P only sometimes, the FE relies on
TYPE_CANONICAL on it otherwise. It is created with
12823 if (TYPE_STRUCTURAL_EQUALITY_P (type))
12824 SET_TYPE_STRUCTURAL_EQUALITY (t);
12825 else if (TYPE_CANONICAL (type) != type)
12826 TYPE_CANONICAL (t) = build_ptrmemfunc_type (TYPE_CANONICAL (type));
and so depends on whether its TYPE_PTRMEMFUNC_TYPE is
TYPE_STRUCTURAL_EQUALITY_P or not.
Jakub
