[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> Ok, so there is one thing that changed (but only very recently) on trunk
> which
> is improved hashing of SCCs and thus more consistent ordering.
> 
> Especially I'm talking about the fact that at compile-time (!) we sort
> via
> 
> static int
> scc_entry_compare (const void *p1_, const void *p2_)
> {
>   const scc_entry *p1 = (const scc_entry *) p1_;
>   const scc_entry *p2 = (const scc_entry *) p2_;
>   if (p1->hash < p2->hash)
>     return -1;
>   else if (p1->hash > p2->hash)
>     return 1;
>   return 0;
> }
> 
> static hashval_t
> hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
> {
>   /* Compute hash values for the SCC members.  */
>   for (unsigned i = 0; i < size; ++i)
>     sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
> 
>   if (size == 1)
>     return sccstack[first].hash;
> 
>   /* Sort the SCC of type, hash pairs so that when we mix in
>      all members of the SCC the hash value becomes independent on
>      the order we visited the SCC.  Disregard hashes equal to
>      the hash of the tree we mix into because we cannot guarantee
>      a stable sort for those across different TUs.  */
>   qsort (&sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
> 
> which means returning 0 from the qsort compare function for hash
> collisions.  In theory the qsort implementation can randomly permute
> stuff here leading to comparison fails.
> 
> I'm checking if breaking the tie via the DFS number fixes the miscompare
> I saw.
> 
> Note that I assumed that "sane" implementations would behave consistently
> here, but of course with address-space randomization and friends and an
> implementation that breaks tie itself via addresses would break.
> (I'd choose a simpler tie breaker - first argument to compare is less
> than second arg to compare).
> 
> Well.  Not sure what glibc msort does here.
> 
> That said, the smallest object I observe differences is build/genconfig.o
> which has differences in the size(!) of the LTO_section_decls section
> and differences already in the decl-state refs part.

Doesn't help.  The list of miscompared files seems to be reproducible at least,
but the actual file contents are different for two compiles.