Hacker News Reader

Comment by bpfrh | Hacker News Reader

Shouldn't same system+same version+same flags produce the same result?

The algorithms used might not produce a deterministic result (like order is different), and maybe it also depends on timings of the CPU with threads scheduled on different cores, or faster/slower cores, etc.

Deterministic builds aren't always that straightforward

I'm using nix and clang/llvm - never have I ever got a different binary.

If what you're saying is true - stage 3 bootstrap wouldn't be possible.

bit obvious, but all it takes something that takes something that changes everytime to make it non-reproducible - like __DATE__ and __TIME__

Nix solves this by forcing __DATE__ and __TIME__ to be a single immutable value in the sandbox for all builds. If you look in the store the file timestamps will be this value.

All C and C++ compilers in common use are single-threaded, and parallelism is achieved by compiling multiple files at once. An optimizer pass producing nondeterministic results due to a bug is not impossible, but would be a bug to fix. Multithreaded linkers which are expected to have nondeterministic results do exist, and you have to not use that for reproduce able builds.

There's a long tail of tricky problems to solve for reproducible builds, but a specific build of a compiler producing different executable code from run to run hasn't really been one of them.

Now I'm wondering how differently my multithreaded tcc fork produces code. I don't think it should but it always wouldn't surprise me if there was some shared state remaining.

Forcing the ordering to be deterministic is a well-established part of the process

https://reproducible-builds.org/docs/stable-inputs/

https://reproducible-builds.org/docs/stable-outputs/

Reply on news.ycombinator.com