[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, IPA ICF dumps show differences like

-  false returned: 'references to virtual tables can not be merged'
(compare_referenced_symbol_properties:371)
+  false returned: 'references to virtual tables can not be merged'
(compare_referenced_symbol_properties:370)

so somehow

        return return_false_with_msg
                 ("references to virtual tables can not be merged");

yields a different line!?  OK, maybe that's host compiler vs. trunk
behavior changes.

But it's also

   congruence class splitted:
-    class with id: 1507, hash: 3773962765, items: 32
-      _Z9gt_ggc_mxR12pending_weak/61270
_Z9gt_ggc_mxR20pending_redefinition/61272 _Z9gt_pch_nxR12pending_weak/61276
_Z9gt_pch_nxR20pending_redefinition/61278
_Z9gt_ggc_mxR20die_arg_entry_struct/200883
_Z9gt_pch_nxR20die_arg_entry_struct/200952
_Z9gt_ggc_mxR23temp_slot_address_entry/286406
_Z9gt_pch_nxR23temp_slot_address_entry/286415
_Z9gt_ggc_mxR15constructor_elt/343972 _Z9gt_ggc_mxR8tree_map/343977
_Z9gt_ggc_mxR13tree_decl_map/343980 _Z9gt_ggc_mxR12tree_vec_map/343986
_Z9gt_ggc_mxR10alias_pair/343989 _Z9gt_ggc_mxR24types_used_by_vars_entry/344011
_Z9gt_ggc_mxR16value_range_base/344099 _Z9gt_ggc_mxR13ipa_edge_args/344069
_Z9gt_ggc_mxR28ipa_polymorphic_call_context/344114
_Z9gt_pch_nxR15constructor_elt/344172 _Z9gt_pch_nxR8tree_map/344177
_Z9gt_pch_nxR13tree_decl_map/344180 _Z9gt_pch_nxR12tree_vec_map/344186
_Z9gt_pch_nxR10alias_pair/344189 _Z9gt_pch_nxR24types_used_by_vars_entry/344211
_Z9gt_pch_nxR16value_range_base/344299 _Z9gt_pch_nxR13ipa_edge_args/344269
_Z9gt_pch_nxR28ipa_polymorphic_call_context/344314
_Z9gt_ggc_mxR15tm_restart_node/344090
_Z9gt_ggc_mxR24constant_descriptor_tree/344060
_Z9gt_pch_nxR15tm_restart_node/344290
_Z9gt_pch_nxR24constant_descriptor_tree/344260
_Z9gt_ggc_mxR13tree_type_map/719494 _Z9gt_pch_nxR13tree_type_map/719499 
+    class with id: 8025, hash: 2249160125, items: 12
+      _Z35gt_ggc_mx_cgraph_indirect_call_infoPv.part.0/346718
_Z35gt_pch_nx_cgraph_indirect_call_infoPv.part.0/346738
_Z22gt_ggc_mx_object_blockPv.part.0/346823
_Z22gt_pch_nx_object_blockPv.part.0/346848
_Z29gt_ggc_mx_ipcp_transformationPv.part.0/346982
_Z29gt_pch_nx_ipcp_transformationPv.part.0/346986
_Z26gt_ggc_mx_machine_functionPv.part.0/346829
_Z21gt_ggc_mx_rtl_bb_infoPv.part.0/346835
_Z26gt_pch_nx_machine_functionPv.part.0/346852
_Z21gt_pch_nx_rtl_bb_infoPv.part.0/346856 _Z15gt_pch_nx_loopsPv.part.0/347044
_Z27gt_pch_nx_rtx_constant_poolPv.part.0/1093864 

that's from

  splitter_class_removed = false;
  split_map.traverse <traverse_split_pair *,
                      sem_item_optimizer::traverse_congruence_split> (&pair);

  /* Bitmap clean-up.  */
  split_map.traverse <traverse_split_pair *,
                      sem_item_optimizer::release_split_map> (NULL);

not sure if there's anything code-gen sensitive but certainly this
pointer-to-X hash_map is dependent on addresses.  It also definitely
makes dumps hard to compare ;)

IPA CP WPA dumps compare equal.

There's a single ltrans file with miscomparing .85t.fixup_cfg3 dump.

--- cc1.ltrans69.085t.fixup_cfg3        2018-12-21 10:01:42.268270515 +0100
+++ ../gcc/cc1.ltrans69.085t.fixup_cfg3 2018-12-21 10:32:55.189589070 +0100
@@ -36748,7 +36748,7 @@
   <bb 2> [local count: 178971752]:
   # DEBUG BEGIN_STMT
   _178 = MEM[(const struct gimple_stmt_iterator &)gsi_57(D)];
-  # DEBUG D#667 => MEM[(const struct gimple_stmt_iterator &)gsi_57(D)]
+  # DEBUG D#668 => MEM[(const struct gimple_stmt_iterator &)gsi_57(D)]
   # DEBUG INLINE_ENTRY NULL

...

DECL_DEBUG_UIDs are off-by-one and we're having differences in debug stmts
as well:

   <bb 56> [local count: 119764]:
-  # DEBUG D#696 => {CLOBBER}
-  # DEBUG actual$D23875$coeffs$0 => D#696
   # DEBUG D#697 => {CLOBBER}
-  # DEBUG expected$D23875$coeffs$0 => D#697
+  # DEBUG actual$D23875$coeffs$0 => D#697
+  # DEBUG D#698 => {CLOBBER}
+  # DEBUG expected$D23875$coeffs$0 => D#698
...
@@ -37739,17 +37739,17 @@
   <bb 65> [local count: 7879806]:
   # DEBUG this => &indices
   # DEBUG INLINE_ENTRY __dt 
-  # DEBUG D#698 => &indices.m_encoding
-  # DEBUG this => D#698
-  # DEBUG INLINE_ENTRY __dt 
-  # DEBUG D#699 => &MEM[(struct int_vector_builder *)D#698].D.12001
+  # DEBUG D#699 => &indices.m_encoding

those differences are really somewhat odd.  materialize-all-clones doesn't
seem to dump anything useful (I see update_ssa output only).

The above shouldn't result in code-gen differences obviously.

Will add more dumps to a next attempt ...