On Fri, Feb 11, 2022 at 12:27:49PM -0500, Jason Merrill wrote:
> Yes, that's what the above code would correctly do if TYPE were the
> pointer-to-method type. It's wrong for this case because TYPE is unrelated
> to TREE_TYPE (field).
>
> I think the problem is just this line:
>
> > if (tree ret = c_fold_indirect_ref_for_warn (loc, type, cop,
> > off))
> > return ret;
> > return cop;
> ^^^^^^^^^^
>
> The recursive call does the proper type checking, but then the "return cop"
> line returns the COMPONENT_REF even though the type check failed. The
> parallel code in cxx_fold_indirect_ref_1 doesn't have this line, and
> removing it fixes the testcase, so I see
>
> warning: ‘*(ptrmemfunc*)&x.ptrmemfunc::ptr’ is used uninitialized
The intent of r11-6729 is that it prints something that helps user to figure
out what exactly is being accessed.
When we find a unique non-static data member that is being accessed, even
when we can't fold it nicely, IMNSHO it is better to print
((sometype *)&var)->field
or
(*(sometype *)&var).field
instead of
*(fieldtype *)((char *)&var + 56)
because the user doesn't know what is at offset 56, we shouldn't ask user
to decipher structure layout etc.
One question is if we could return something better for the TYPE_PTRMEMFUNC_FLAG
RECORD_TYPE members here (something that would print it more naturally/readably
in a C++ way), though the fact that the routine is in c-family makes it
harder.
Another one is whether we shouldn't punt for FIELD_DECLs that don't have
nicely printable name of its containing scope, something like:
if (tree scope = get_containing_scope (field))
if (TYPE_P (scope) && TYPE_NAME (scope) == NULL_TREE)
break;
return cop;
or so.
Note the returned cop is a COMPONENT_REF where the first argument has a
nicely printable type name (x with type sp), but sp's TYPE_MAIN_VARIANT
is the unnamed TYPE_PTRMEMFUNC_FLAG. So another possibility would be if
we see such a problem for the FIELD_DECL's scope, check if TYPE_MAIN_VARIANT
of the first COMPONENT_REF's argument is equal to that scope and in that
case use TREE_TYPE of the first COMPONENT_REF's argument as the scope
instead.
Jakub
