Re: [boost] [predef] Fails on Intel/win

Subject: Re: [boost] [predef] Fails on Intel/win
From: Blower, Melanie (melanie.blower_at_[hidden])
Date: 2015-07-21 10:00:24

On 21/07/2015 03:56 John Maddock wrote:
...
>I'll experiment later and report back,

Wow, thank you very much. 

The patch I've been testing in house is (attached). I haven't tried entirely skipping common_edg. There was also a typeof problem which had to do with the Intel compiler specific tailoring, so there's a patch for that file too. I was using the library_test_all regression testing and found that many type_traits tests (small test case attached) were newly failing on Linux, so I added "pragma warning disable" which you can see in the attached patch, after that the regression testing was same on Linux before and after the patch. On Windows there were many new passes and some apparent new failures, but that was due to entirely new code being included, and we would create compiler bug reports about each of those.  At the end of the day, the Intel compiler team would prefer to have boost sources not be customized for the Intel compiler to work around deficiencies, but instead we would prefer to receive bug reports.

Best regards, Melanie Blower

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
Sent: Tuesday, July 21, 2015 3:56 AM
To: boost_at_[hidden]
Subject: Re: [boost] [predef] Fails on Intel/win

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost