[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 8 Nov 2019, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
> 
> --- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
> > 
> > more complex "ranges" for debug counters appreciated,
> 
> +1
> 
> > -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> > I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.  Guess
> > {} don't work very well due to shell limitations so maybe
> > simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
> 
> Note that the debug counter is mainly for us as developers, so I would not
> care much about backward compatibility.
> 
> > Implementation-wise we'd have instead of high/low arrays
> > an array of pair<counter, vec<pair<high, low> > which we only look at
> > the last element of the vec (sort it backwards), popping it whenever
> > we reach it's max and checking against the current min.  or some
> > other data structure mimicing this, that is, dbg_cnt () is still O(1)
> > just parsing the option might involve sorting.
> 
> Yes, one simple improvement can be:
> foo:5-6:9:10-100:1000 where we can enforce that ranges are in increasing
> order and not overlapping. Or we can sort the ranges and then dbg_cnt will
> be O(1) with the popping technique.

This simple improved format works for me.  For users sake I'd simply sort
the thing since we're going to need to reverse it anyways.  Then
-fdbg-cnt=foo:5 -fdbg-cnt=foo:1-3 would also be inclusive, effectively
setting 1-3:5?