On 11/26/25 2:55 PM, 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.
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.
I wouldn't expect that to be an issue, the POINTER_TYPE to
METHOD_TYPE.is immediately wrapped in the PMF RECORD_TYPE.
The comment suggests that the problem is that METHOD_TYPE isn't
canonicalized properly, but build_method_type_directly sure seems to
work to do that, so perhaps the comment is obsolete and we can just
return -1?
That comment goes back to r81764
(6de9cd9a886ea695aa892c3c7c07818a7b7e9e6f), the tree-ssa merge.
Jason
