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.
