Re: Unstable build/host qsorts causing differing generated target code

Am 2018-01-12 um 19:45 schrieb Jeff Law: On 01/12/2018 11:26 AM, Cory Fields wrote: Quick disclaimer: I'm 100% new to GCC code and the dev process, so there are bound to be some faulty assumptions below. I recently worked on a build of gcc, x86_64-pc-linux-gnu -> x86_64-pc-linux-musl. In order

Re: Unstable build/host qsorts causing differing generated target code

Hi, On Fri, 12 Jan 2018, Joseph Myers wrote: > On Fri, 12 Jan 2018, Alexander Monakov wrote: > > > No. The qsort_chk effort was limited to catching instances where comparators > > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > > transitivity property (may indicate A < B

Re: Unstable build/host qsorts causing differing generated target code

On Fri, 12 Jan 2018, Joseph Myers wrote: > On Fri, 12 Jan 2018, Alexander Monakov wrote: > > > No. The qsort_chk effort was limited to catching instances where comparators > > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > > transitivity property (may indicate A < B < C <

Re: Unstable build/host qsorts causing differing generated target code

On Fri, 12 Jan 2018, Alexander Monakov wrote: > No. The qsort_chk effort was limited to catching instances where comparators > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > transitivity property (may indicate A < B < C < A). Fixing them doesn't > imply making

Re: Unstable build/host qsorts causing differing generated target code

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

Re: Unstable build/host qsorts causing differing generated target code

On Fri, 12 Jan 2018, Jeff Law wrote: > THe key here is the results can differ if the comparison function is not > stable. That's inherent in the qsort algorithms. I'm afraid 'stable' is unclear/ambiguous in this context. I'd rather say 'if the comparator returns 0 if and only if the items being

Re: Unstable build/host qsorts causing differing generated target code

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

Re: Unstable build/host qsorts causing differing generated target code

On Fri, Jan 12, 2018 at 01:54:25PM -0500, Cory Fields wrote: > Thanks for letting me know about this effort. That's great news! > > Indeed, I ran into less of these issues on trunk. I'll go ahead and > submit patches for the cases that turned up there. The qsort checking failures are tracked in

Re: Unstable build/host qsorts causing differing generated target code

On Fri, Jan 12, 2018 at 1:45 PM, Jeff Law wrote: > On 01/12/2018 11:26 AM, Cory Fields wrote: >> Quick disclaimer: I'm 100% new to GCC code and the dev process, so >> there are bound to be some faulty assumptions below. >> >> I recently worked on a build of gcc,

Re: Unstable build/host qsorts causing differing generated target code

On 01/12/2018 11:26 AM, Cory Fields wrote: > Quick disclaimer: I'm 100% new to GCC code and the dev process, so > there are bound to be some faulty assumptions below. > > I recently worked on a build of gcc, x86_64-pc-linux-gnu -> > x86_64-pc-linux-musl. In order to boost my confidence in musl, I

Unstable build/host qsorts causing differing generated target code

Quick disclaimer: I'm 100% new to GCC code and the dev process, so there are bound to be some faulty assumptions below. I recently worked on a build of gcc, x86_64-pc-linux-gnu -> x86_64-pc-linux-musl. In order to boost my confidence in musl, I decided that I'd like to ensure that 3 (and 4) stage