Describe the problem
The linking step of the intel compiler during bisect was developed using the assumption that GCC is the ground-truth compilation.
The ground-truth compilation is configurable, so that needs to be checked instead of assumed
The reverse-engineering that was done with the linking back when it was developed has changed, and linker errors ensue
Intel is allowed to and will change the way their compiler works. It is too much work to try to keep up how to reverse engineer every version of the intel compiler
Suggested Fix
We can still do the test of comparing the ground-truth executable with the executable with all object files compiled with the ground-truth executable, but linked with the trouble compilation. It does not require reverse-engineering the required linker flags from the intel compiler. Instead, simply use the intel compiler to link the object files. This seems like a no-brainer.
The reason it was done this way in the past is because we were hoping to be able to bisect the libraries to be able to determine which functions within those included libraries were introducing variability. Unfortunately, we didn't have equivalent libraries with the old implementation, but the new symbol names. Therefore, it was a bust, and the hack solution was kept in because it worked at the time.
Furthermore, there should be an approach that is agnostic to the ground-truth compilation that is chosen.
It would be nice to add automated tests that only run when an intel compiler is present.
Alternative approaches:
Give up on the intel compilations that require extra libraries
Give up on the intel compilations that have variability when only linked with the intel compiler
Reverse engineer the newer intel compilers to see how to get them working with the ground-truth compiler as a linker
See if there is a way to grab the necessary link flags from the intel compiler
Note: the failure was not at link-time, but rather a linker error at runtime. They were missing symbols, such as undefined reference to _intel_fast_memcpy.
Bug Report
Describe the problem The linking step of the intel compiler during bisect was developed using the assumption that GCC is the ground-truth compilation.
Suggested Fix We can still do the test of comparing the ground-truth executable with the executable with all object files compiled with the ground-truth executable, but linked with the trouble compilation. It does not require reverse-engineering the required linker flags from the intel compiler. Instead, simply use the intel compiler to link the object files. This seems like a no-brainer.
The reason it was done this way in the past is because we were hoping to be able to bisect the libraries to be able to determine which functions within those included libraries were introducing variability. Unfortunately, we didn't have equivalent libraries with the old implementation, but the new symbol names. Therefore, it was a bust, and the hack solution was kept in because it worked at the time.
Furthermore, there should be an approach that is agnostic to the ground-truth compilation that is chosen.
It would be nice to add automated tests that only run when an intel compiler is present.
Alternative approaches: