[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69117

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Jan 2016, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69117
> 
> --- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Hmm, OK, what seems to be done is the following.  We end up calling 
> vn_reference_lookup_3 on
>  *e.3_12 = g.4_13;
> but we valueize the LHS as
> (gdb) p debug_generic_stmt (base1)
> MEM[(int * *)_10];
> 
> this seems fine. Eventually we call indirect_ref_may_alias_decl_p and that
> takes away the MEM_REF comparing *_10 with d and that returns false in:
> 
>   /* They also cannot alias if the pointer may not point to the decl.  */       
>   if (!ptr_deref_may_alias_decl_p (ptr1, base2))                                
>     return false;                                                               
> 
> I think ptr_deref_may_alias_decl_p can not ignore type from MEM_REF.

It uses points-to info only so yes, it can.  The points to set of
_10 is empty:

  <bb 3>:
  MEM[(int * * * *)0B] = &e;
  _9 = MEM[(int * * *)0B];
  _10 = *_9;
  *_10 = 0;

there is "no object" at 0B and thus it doesn't contain any pointers.

To me the question is why we value-number e.3_12 to _10.  Ah,
that's because we value-number it that way and thus we get
a conflict between "points-to what e points to" and "nothing".

Umm.

I think the testcase is simply undefined if it were running into
the if (c) case and this is a case of false equivalency (we have
similar issues with points-to pointed out in another PR with
a quite lengthy audit-trail... can't find it right now).

This is another interesting case :/  Basically we'd need to
handle the zero-address-based access by not value-numbering it.

It's also quite artificial.

What's new now is that

 *_10 = 0;

no longer is thought to eventually clobber *_9.