On 20/07/2015 14:12, Blower, Melanie wrote:
Hello!
I work on the Intel C++ compiler, and part of my work involves investigating bug reports about compilation failures involving boost.
We've been developing a patch for the "intel.hpp" and "common_edg.hpp" configuration files which relate to the topic that you were discussing in this email. I'd like to sketch out the patch to see if you think it would be acceptable to the boost community.
Separately, I'm curious if you plan to change boost to take advantage of the C++ "feature test" macros N3694. They will see some use yes, especially the (predefined) compiler ones, although there are issues surrounding the library ones that have been discussed at length already. In this email thread, you used the term "emulate". At Intel we call it "compatibility", and we endeavor to be compatible with our host compiler, e.g. gcc on Linux and Visual Studio on Windows. For example, if the host compiler is vs2013, there are different c++ features available than if the host compiler is vs2015. Also, although we take the C++ implementation from EDG we make customizations in-house, at times implementing a C++ feature ahead of when we get it from EDG.
Down to the nuts and bolts question about the Intel compiler configuration. The patch we've been investigating basically looks like this
That's similar to what we do with the CUDA compiler, so yes it's a viable option, I would make the changes to intel.hpp and stop including common_edg.hpp altogether though. Also note that there may well be library specific workarounds in place which cause different code to be compiled for Intel vs GCC, not just configuration issues. I'll experiment later and report back, Regards, John.