This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux and Windows generate different binaries


On Thu, Jul 13, 2017 at 4:56 AM, Klaus Kruse Pedersen (Klaus)
<klauskpedersen@rdamicro.com> wrote:
> On Wed, 2017-07-12 at 08:57 -0600, Sandra Loosemore wrote:
>> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>> > I have seen reproducible builds being discussed here, but what is
>> > the
>> > position on inter c-lib and OS reproducible builds?
>>
>> I think we consider unstable sort problems bugs and have fixed them
>> in
>> the past.  Bugzilla search turned up #28964 and I remember at least
>> one
>> more recent instance of this as well (although not the details any
>> more).
>
>
> Yes, 28964 is similar to the issue I was hit by.
>
> By extension, does that mean that all qsort compare/rank functions that
> can return 0, should be considered buggy?
>
> I went through a some of the 140'ish rank functions - and it does
> indeed look like considerable effort went into returning only +1 and
> -1.
>
> A general pattern seem to be:
>
>         return da ? 1 : -1;
>
> And comments like:
>
>   /* If regs are equally good, sort by their numbers, so that the
>      results of qsort leave nothing to chance.  */
>
>
> But there are exceptions, all rank functions in
>
>         tree-ssa-loop-ivopts.c,
>         tree-ssa-loop-niter.c
>         tree-ssa-loop-im.c
>
> can return 0.

One more issue with some of qsort callbacks is that they do not always
satisfy ordering axioms which in practice may result in random
variations in output. I once reported this in
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02141.html but didn't
follow up.

-Y


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]