https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Component|middle-end |c++
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Obviously
<bb 5> :
_31 = &MEM[(const struct variant *)__for_begin_7].D.26373.f1;
_1 = _31->__pfn;
...
<bb 6> :
_3 = _31->__delta;
do not alias the stores somehow.
const struct
{
void MyStruct::<T42b7> (struct MyStruct *, int) * __pfn;
long int __delta;
} * _31;
for example _31->__delta gets alias-set 4 and the store alias-set 6. It looks
like the C++ FE creates separate pfn structure types without any TBAA measure
here? In this case the method type we create them are different.
void MyStruct::<T4316> (struct MyStruct *, int)
and
int MyStruct::<T431a> (struct MyStruct *, char, short int, bool)
I cannot decipher the C++ testcase enough to see how this happens or whether
that is desired (I see there's an anonymous union present, but while one
access might be through the union type the above pointer indirection is not).
It looks to me that the C++ FE for the 'auto' resolution in
for (auto &anyFunc : get_member_functions<Class>())
uses a bogus (the "first") type. Whether that's a bug in the new for()
syntax implementation or sth else isn't entirely clear to me. Maybe it
needs to build a "generic" PFN type for this iterator.
-> C++ FE issue.
