On Wed, 26 Nov 2025, Jakub Jelinek wrote: > 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.
So should get_alias_set then re-query the frontend for the pointed-to type in its pointer handling? As said, I fear the proposed change is incomplete (so was the previous handling, of course). Richard. > Jakub > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
