boost compilation options (binary compatibility)

[firespot71]

Hi,

If boost (1.50; Windows) is built using icl and leaving compilation options on default as provided by the boost build scripts, which options may be incompatible if these libs get (statically) linked to an application compiled under different options? (OK I know in theory unless all are identical, no guarantee. It's a practical question as it's very tedious building boost for each and everything that might change).

For example, would you expect problems for differing options regarding, e.g., /O3 /Oi /Ot /GT /Qipo /GF /Gy, or specific instruction sets (/arch; presume of course the target machine supports them), /fp and /Qfp-speculation, /Qrestrict and so forth? One option I'd be particularly careful about is /Quse-intel-optimized-headers, but I might be wrong here of course.

any suggestiongs / pointers very welcome !
Thanks

[TimP]

A majority of the options you mentioned have only local effect. I find it somewhat difficult myself to get my head around combinations of Microsoft-spelled and Intel-spelled options.
Intel optimized headers means some substitutions of IPP library functions for ordinary Microsoft ones in standard headers, so that option (and /Qipo) could pose complications in a build which uses a mixture of Microsoft and Intel compilers.
The Intel compilers have reduced the number of situations where the same options have to be specified in the link step in order to get the library dependencies satisfied automatically, but CL would not be able to handle ipo objects nor would it search the ICL libraries automatically.
Going the other way, ICL can't handle CL /GL objects, but it would satisfy library dependencies automatically for both Microsoft and ICL objects. Should you happen to use CL OpenMP in a mixed build, you should force the use of the ICL libiomp5 in place of CL vcomp, so the parallel options (including /Qparallel) are another possible complicating factor.
I suppose most people would stick with widely accepted options for boost compilation, until profiling for hotspots and testing shows a benefit for changes on specific functions.

[firespot71]

The build uses exclusively ICL for compilation (what MSVC libs ICL relies on is a different story of course), with boost getting built in a first step (using the intel toolset configuration provided by boost) and then linked to an application built with ICL. Hence no mixed build.
I am less concerned about performance of the boost compilation (though a lot regarding my application, hence the fairly aggressive optimization there), but I am concerned if ABI compatibility should be provided for a standard boost build (using the default intel-toolset configuration) if above options are set for the other units. That beign said I have built that executable and no problems so far, but of course they may just have not become symptomatic yet.

Going the other way, would Intel linking tools generally detect an incompatibility between compilation units?
Would you strongly suggest that if some object files were compiled with /Qipo, /Qparallel and /Quse-intel-optimized-headers, then they should link to boost libraries built using the same options (again assuming everything was build using ICL)?

thanks and best regards