Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Reproducible build

maartenb
New Contributor I
1,189 Views

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?

Thanks,
Maarten

0 Kudos
7 Replies
jimdempseyatthecove
Honored Contributor III
1,169 Views

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.

Jim Dempsey

0 Kudos
maartenb
New Contributor I
1,161 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,157 Views

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.

Jim Dempsey

0 Kudos
maartenb
New Contributor I
1,148 Views

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.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,144 Views

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.

Jim Dempsey

0 Kudos
maartenb
New Contributor I
1,138 Views

Thanks. I'll look into that and get back to you.

0 Kudos
Steve_Lionel
Honored Contributor III
1,125 Views

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.

0 Kudos
Reply