On Wed, 26 Nov 2025, Jakub Jelinek wrote: > On Wed, Nov 26, 2025 at 10:05:27AM +0100, Richard Biener wrote: > > > 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). > > The get_alias_set of TYPE_PTRMEMFUNC_P will be always 0, so another > possibility is just undo that part of your change and return -1 form > POINTER_TYPE/REFERENCE_TYPE to TYPE_PTRMEMFUNC_P. > Or drop the TYPE_PTRMEMFUNC_P handling from cxx_get_alias_set altogether, > maybe it was needed 2 decades ago but isn't anymore.
Yeah, I don't remember - IIRC I did this as part of the GIMPLE type checking work, and I possibly only tried to play safe. > Unfortunately, already the FE does some get_alias_set calls (e.g. for > strict alias warning) and those can remember stuff. I think the problem > with TYPE_PTRMEMFUNC_P is that it is initially in the IL as POINTER_TYPE > to METHOD_TYPE and only later lowered to these TYPE_PTRMEMFUNC_P > (RECORD_TYPE with magic flag). Though perhaps that lowering happens early > enough that the get_alias_set calls in strict alias warning stuff already > see the TYPE_PTRMEMFUNC_P only. Hmm, I see. I do remember PMF were a PITA with respect to canonical types and type verification. Richard.
