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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-04-20
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the bug is that sccvn uses DECL_UIDs in hash computations, so in some
cases we end up with different hashcodes, different collisions and if unlucky
enough, e.g. vn_phi_lookup can find a different value based on that.
If I instrument:
@@ -3120,6 +3120,9 @@ vn_phi_insert (gimple *phi, tree result)
   vp1->result = result;
   vp1->hashcode = vn_phi_compute_hash (vp1);

+fprintf (stderr, "vn_phi_insert %08x %d %d\n", vp1->hashcode, TREE_CODE
(result) == SSA_NAME ? SSA_NAME_VERSION (result) : -1);
+extern void debug_gimple_stmt (gimple *);
+debug_gimple_stmt (phi);
   slot = current_info->phis->find_slot_with_hash (vp1, vp1->hashcode, INSERT);

   /* Because we iterate over phi operations more than once, it's
I see:
 vn_phi_insert 127d0253 12 146
 .MEM_12 = PHI <.MEM_13(D)(2), .MEM_26(3)>
-vn_phi_insert e38159ce 29 146
-_29 = PHI <&D.834312(2), &D.834311(3)>
-vn_phi_insert e38159ce 29 146
-_29 = PHI <&D.834312(2), &D.834311(3)>
+vn_phi_insert 851182e7 29 146
+_29 = PHI <&D.834716(2), &D.834715(3)>
+vn_phi_insert 851182e7 29 146
+_29 = PHI <&D.834716(2), &D.834715(3)>
 vn_phi_insert 77edc47d 9 146
 .MEM_9 = PHI <.MEM_13(4), .MEM_14(3)>

While -g vs. -g0 guarantees the bbs and SSA_NAME_VERSIONs etc. are always the
same, we don't have any such a guarantee for DECL_UIDs, there is just a
guarantee that the corresponding DECL_UIDs in between -g and -g0 compare the
same, but they can have different gaps in between them.

Not really sure what is the way out of this (nor does this really look like a
recent regression, it is just something really hard to reproduce, one has to be
unlucky enough).  Perhaps in inchash::add_expr optionally use a DECL_UID -> uid
hash map if the caller asks for it, which would map DECL_UIDs (only if seen in
non-debug stmts) to say visit #s.  Or try to guarantee identical DECL_UIDs
between -g and -g0 (we'd need to have some flag for decl creation in "debug
only" contexts and use say negative uids, dunno if we'd need to be prepared to
bump those "debug only" uids into normal uids if they are looked up in
non-"debug only" contexts later on.

Reply via email to