On Thu, 23 Jan 2020, David Malcolm wrote: > Removing the assertions fixes it for me (a stage1 build, at least, and > it then passes the testsuite). > > I've made this blunder in four places in the analyzer: > > call-string.cc:162: call_string::cmp > program-point.cc:461: function_point::cmp_within_supernode
These two don't raise concerns on brief inspection. > engine.cc:1820: worklist::key_t::cmp This one tries to use signed difference of hashes as return value, this is not going to work in general while passing your assert almost always (except when difference of hashes is exactly -2^31). The problem is, difference of hashes leads to non-transitive comparison and qsort_chk can catch it on a suitable testcase. > region-model.cc:1878: tree_cmp This is the one under discussion here. > IIRC, I added these checks as I was finding it difficult to debug > things when qsort_chk failed - the first three of the comparators in > the list above build on each other: worklist::key_t::cmp uses both > function_point::cmp_within_supernode and call_string::cmp (and various > other things), so if the worklist qsort_chk fails, it sometimes > required a fair bit of digging into which of the nested comparators had > failed (also, all the void * don't help; I'd love to have a template > that does a typesafe qsort without needing casts in the comparator). FWIW qsort_chk_error is a separate function to make that easier: if you place a breakpoint on qsort_chk_error you just need to step a few times to get into a comparator that is under suspicion, and don't need to type out casts in gdb. Alexander
