On Wed, Oct 15, 2025 at 11:11:23AM +0200, Jan Hubicka wrote: > Hi, ... > diff --git a/gcc/bb-reorder.cc b/gcc/bb-reorder.cc > index 641b4928ffb..e4efdee0b16 100644 > --- a/gcc/bb-reorder.cc > +++ b/gcc/bb-reorder.cc > @@ -2389,8 +2389,10 @@ edge_order (const void *ve1, const void *ve2) > /* Since profile_count::operator< does not establish a strict weak order > in presence of uninitialized counts, use 'max': this makes them appear > as if having execution frequency less than any initialized count. */ > - profile_count m = c1.max (c2); > - return (m == c2) - (m == c1); > + gcov_type gc1 = c1.initialized_p () ? c1.to_gcov_type () : 0; > + gcov_type gc2 = c2.initialized_p () ? c2.to_gcov_type () : 0; > + gcov_type m = MAX (gc1, gc2); > + return (m == gc1) - (m == gc2); Hi Jan,
Shouldn't this line preserve the original comparison order? In particular, shouldn't it be: + return (m == gc2) - (m == gc1); Per comments in reorder_basic_blocks_simple(), edges should be sorted "most desirable first.". Which I interpret as edges with highest m_val should be first. Yet with this patch applied I see the reverse: (gdb) break bb-reorder.cc:2449 (gdb) p edges[0]->count().m_val $10 = 365072224 (gdb) p edges[1]->count().m_val $11 = 708669600 (gdb) p edges[2]->count().m_val $12 = 708669600 (gdb) p edges[3]->count().m_val $13 = 1073741824 (gdb) p edges[4]->count().m_val $14 = 1073741824 Regards, Dimitar > } > > /* Reorder basic blocks using the "simple" algorithm. This tries to
