4 ms·

Reproducibility is an entirely unrelated issue. The same compiler can produce different assembly for the same code depending on the surrounding context, or any

Reproducibility is an entirely unrelated issue. The same compiler can produce different assembly for the same code depending on the surrounding context, or any number of other reasons. A reproducible build just means that you'll get the same binary each time you build it. Furthermore, the same generated assembly can produce different results each time it's run, as data races do. In that case, the only "definition" comes down to the essentially unknowable physical state of the system.

charcircuit 3y ago
>Reproducibility is an entirely unrelated issue. No, reproducibility is about having a defined output for a given source code and toolchain.
- AlotOfReading 3y ago
  I wrote up a quick example demonstrating UB compiling to two different implementations: https://godbolt.org/z/nd7GrP44s https://godbolt.org/z/nd7GrP44s Ignore how silly the actual code is and notice that the -O0 assembly checks the pointers before dereferencing them while the -O2 assembly does not. Same compiler, same translation unit, different assembly. Calling each with null pointers will behave differently too. Run this with whatever reproducible toolchain you want. Reproducible builds are not about making undefined behavior deterministic, they're a separate and largely unrelated topic.
  - charcircuit 3y ago
    In order to make this example you showed me you were successfully able to reason about the output of the compiler despite using UB. You understood how things were defined differently for different optimization levels.
    - AlotOfReading 3y ago
      Being able to reason about a particular instance of a particular compiler on a specific undefined construct does not imply UB is defined generally.
      - charcircuit 3y ago
        I never said it is defined generally. I said that it eventually gets defined as in it may come down to the source code of a specific version of the compiler that defines the behavior.

charcircuit 3y ago

>Reproducibility is an entirely unrelated issue. No, reproducibility is about having a defined output for a given source code and toolchain.

AlotOfReading 3y ago
I wrote up a quick example demonstrating UB compiling to two different implementations: https://godbolt.org/z/nd7GrP44s https://godbolt.org/z/nd7GrP44s Ignore how silly the actual code is and notice that the -O0 assembly checks the pointers before dereferencing them while the -O2 assembly does not. Same compiler, same translation unit, different assembly. Calling each with null pointers will behave differently too. Run this with whatever reproducible toolchain you want. Reproducible builds are not about making undefined behavior deterministic, they're a separate and largely unrelated topic.
- charcircuit 3y ago
  In order to make this example you showed me you were successfully able to reason about the output of the compiler despite using UB. You understood how things were defined differently for different optimization levels.
  - AlotOfReading 3y ago
    Being able to reason about a particular instance of a particular compiler on a specific undefined construct does not imply UB is defined generally.
    - charcircuit 3y ago
      I never said it is defined generally. I said that it eventually gets defined as in it may come down to the source code of a specific version of the compiler that defines the behavior.