[Bug c++/91606] [9/10 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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.