https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to sandra from comment #18)
> Hmmm, it looks to me like things are going wrong in the tree fre1 pass too.
> I commented out the redundant zero store in the test case to see what would
> happen, like
>
> long __attribute__((noipa))
> foo (struct bb *bv, void *ptr)
> {
> struct aa *a = ptr;
> struct bb *b = ptr;
> bv->b.u.f = 1;
> a->a.u.i = 0;
> /* b->b.u.f = 0; */
> return bv->b.u.f;
> }
>
> fre1 gets this as input:
>
> __attribute__((noipa, noinline, noclone, no_icf))
> foo (struct bb * bv, void * ptr)
> {
> struct bb * b;
> struct aa * a;
> long int _8;
>
> <bb 2> :
> bv_5(D)->b.u.f = 1;
> MEM[(struct aa *)ptr_1(D)].a.u.i = 0;
> _8 = bv_5(D)->b.u.f;
> return _8;
>
> }
>
>
> and produces this output:
>
> __attribute__((noipa, noinline, noclone, no_icf))
> foo (struct bb * bv, void * ptr)
> {
> struct bb * b;
> struct aa * a;
>
> <bb 2> :
> bv_5(D)->b.u.f = 1;
> MEM[(struct aa *)ptr_1(D)].a.u.i = 0;
> return 1;
>
> }
>
> This is with -O2.
>
> Again, it seems like something is not realizing that pointer parameters can
> be aliased no matter what their types are. Or perhaps that is just a
> symptom of some other underlying bug. :-S
No, it's a feature and called type-based alias-analysis. The "redundant"
store is what eventually aliases with the load, the other store to the
same location can be disambiguated using TBAA. So the second store is
not really redudnant - while it has no effect on the bits in the memory
it alters the memory state by changing the effective type of the memory
location to one compatible with the following load (or since we're dealing
with unions, it changes the active union member). This is why we cannot
elide the "redudnant" store. We can elide the earlier store as dead
though (since there's no intermediate use).
