Yes, this is the issue that I ran into. I took the check further by asserting that if cmp(A, B) == 0, memcmp(A, B) == 0 as well. But that''s tricky because the structure may contain data that differs from A to B, but ultimately isn't used after the sort. So it leads to a bunch of false-ish-positives. Though arguably even those cases should be fixed as well.
Out of curiosity, other than bloat, what would be the downside of using an internal sort? It would also have the benefit of allowing more rigorous stability checks. On Fri, Jan 12, 2018 at 2:37 PM, Alexander Monakov <amona...@ispras.ru> wrote: > On Fri, 12 Jan 2018, Jakub Jelinek wrote: >> The qsort checking failures are tracked in http://gcc.gnu.org/PR82407 >> meta bug, 8 bugs in there are fixed, 2 known ones remain. > > Note that qsort_chk only catches really bad issues where the compiler > invokes undefined behavior by passing an invalid comparator to qsort; > differences between Glibc and musl-hosted compilers may remain because > qsort is not quaranteed to be a stable sort: when sorting an array {A, B} > where > A and B are not bitwise-identical but cmp(A, B) returns 0, the implementation > of > qsort may yield either {B, A} or {A, B}, and that may cause codegen > differences. > > (in other words, bootstrapping on a libc with randomized qsort has > a good chance to run into bootstrap miscompares even if qsort_chk-clean) > > Alexander
