This is the mail archive of the
mailing list for the GCC project.
Re: gcc-4.9.1 generating different code between two successive builds
- From: Cole <cole at opteqint dot net>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 22 Dec 2015 08:30:32 +0200
- Subject: Re: gcc-4.9.1 generating different code between two successive builds
- Authentication-results: sourceware.org; auth=none
- References: <CACsf_wwETk+L6eq0HoL0Hz8sa-CZdntZVtjGk4aY8D1989vMqw at mail dot gmail dot com> <56784E11 dot 8050406 at gmail dot com>
Thanks very much for the suggestions as well as all the information
about the qsort issues.
Did you ever publish your changes as a patch, or create a write up
about what was necessary to create a reproducible build? I would be
interested to see what others have done, and potentially anything else
I may have missed.
On 21 December 2015 at 21:08, Martin Sebor <firstname.lastname@example.org> wrote:
> On 12/20/2015 11:39 PM, Cole wrote:
>> I am busy trying to generate a package for gcc that is consistent
>> between two successive builds, and I am now down to the final few
>> I am stuck with the file: cilk-abi-cilk-for.o, which is obviously
>> built with -O2, but between two successive builds, the assembly code
>> generated is different. Please refer to  for output and details.
>> Would anyone have any suggestions that I might be able to try to get
>> the file to generate the same assembly code?
> It's been some time since I had to deal with this problem and
> my recollection is somewhat fuzzy and probably inaccurate. IIRC,
> part of it was caused by qsort being unstable (I think that was
> on Solaris). We replaced it with a stable version. Another part
> of it might have been caused by changes in the address space
> layout caused by ASLR (causing differences in hash values used
> by the register allocator or something like that). We disabled
> ASLR to get around that (and other problems). With that, we had
> fully repeatable builds. This was in the GCC 4.5 time frame.
> With newer versions, there's also LTO that can affect things.
> The -frandom-seed= option exists to make it possible to emit
> identical object files that might otherwise be different.