https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125252
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
IVOPTs does
struct
{
struct S * (*<T3f9>) (void) get_headerD_2965;
} reply_to_mapD_2967[2];
...
__BB(3,loop_header(1),guessed_local(715863672)):
- i_13 = __PHI (__BB5: i_10, __BB2: 0);
- _4 = __PHI (__BB5: _3, __BB2: 2u);
- _1 = reply_to_mapD_2967[i_13].get_headerD_2965;
+ ivtmp.10_12 = __PHI (__BB5: ivtmp.10_11, __BB2: ivtmp.10_16);
+ _17 = (voidD_54 *) ivtmp.10_12;
+ _1 = __MEM <struct S * (*<T3f9>) (void)> ((struct S * (*<T3f9>) (void)
*)_17);
_2 = _1 ();
__asm__ __volatile__("" : : "r" _2);
so it replaces the reply_to_mapD_2967[i_13].get_headerD_2965 access
with the __MEM which uses the alias set of the get_header member. I think
that's correct.
The structure based accesses will also use the structure type as
way to disambiguate, so likely the C frontend setup fails to have
the get_header member TBAA set recorded as subset of whatever it
uses as "canonical" structure type.
