I'm trying to create a reproducible build with Intel Fortran on Windows 10. Essentially, I want two builds run at different points in time (and ideally also different systems with the same OS) to result in exactly the same binary, reflected by identical checksums.
The MS linker has an undocumented setting "/Brepro" that assures this. If I use this setting and repeat the link step the resulting binary will indeed be the same. However, if I perform a complete clean, recompile all modules, and link, the binaries are different So the Fortran compiler introduces variation.
Is there a setting similar to /Brepro for the Fortran compiler that achieves reproducible builds?
This (different binary checksums of output data) sounds like code and/or static data placement sensitivity, and/or possibly different heap and/or stack location within the VM address space sensitivity.
These differing placements (of non-buggy code) could have a potential code path selection difference in optimized code where one build differs in the peal (data alignment at start of loop), vector part of loop, and remainder.
To correct for this, use the directives to assure alignment of data that may be processed using vectors.
Thanks for your reply. However I'm not sure if we're talking about the same thing. I'm not talking about the output data of my program, but about the actual executable (exe.). I need this for an automatic versioning system that checks whether the exe has changed using a checksum, and based this decides whether a rerun is necessary.
Builds performed on the same system but at different points in time result in differences in the exe. A quick analysis on an object file shows that there is an embedded time stamp, but I'm not sure if this makes it to the final executable. There are also other differences however.
Since the Linker is the cause of the issue, why not checksum the .obj files instead?
Note, even with check-summing the .exe (built) on different systems will not guarantee that the same program runs on those different systems. Windows .exe's invariably use .dll's and/or different Windows Updates that can affect the runtime behavior.
The .exe checksum tells you something is different, whereas the .obj checksum will tell you where the difference (if any) occurs.
Actually the linker is *not* the cause of the issue, since the /Brepro linker flag assures an identical exe as long as the object files are the same. But the problem is that there are differences in the object files, between successive compiles (within minutes) on the same system. I checked an object file using dumpbin, but other than the timestamps I can't really make sense of the differences.
I see your point on changes in dlls. My code actually doesn't explicitly use them, but some might be used anyway without me knowing. But right now I'd settle for identical builds on the same system.
Pending an answer from Intel compiler developers....
Using the .obj outputs from two compiles of your smallest .obj that shows a difference. (keep both)
Build two .exe's with /Brepro
Verify: a) entry point of the .obj procedure starts at the same address (VTune dissassembly or Debug disassembly), and b) instructions are the same.
I know that compiled module files (.mod) have a date/timestamp indicating when it was compiled. A brief test suggests that compiled object files (.obj) have a timestamp as well in the first eight bytes. Microsoft documentation on the PE format says there are timestamps.