On Jan 19, 2015, at 10:14 AM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> wrote: > On Jan 19, 2015, at 6:48 PM, Mike Stump <mikest...@comcast.net> wrote: >> On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> >> wrote: >>> In A < B < C < A case all A, B and C are normal instructions. It is a >>> pre-existing condition. When compiling without debug information we have >>> ready list "A, B, C". When compiling with debug information, we have ready >>> list "A, B, C, D" where "D" is DEBUG_INSN. Because we now have 4 elements >>> to sort instead of 3, qsort can choose a different order of comparison >>> _among_ A, B and C. >> >> Not when the uid is mixed in it cannot. :-) > > I think you are misunderstanding the issue.
If all the required elements are mixed into the comparison operator, then only 1 ordering is possible, it is stable and reliable across machines, and that ordering is the same as the ordering that you would get of those instructions if other instructions were present or not, including by not limited to debug instructions. In such a stable sort, it is not possible that the comparison order can ever matter, by definition. I think you’re saying the ordering relation is screwed. The solution I like, is to fix it. Trying to hide a broken ordering relation with obscure code without fixing the underlying problem, strikes me as not the path forward. Perplexed.
