[predef] Fails on Intel/win

John Maddock

12 Jul 2015 12 Jul '15

8:42 a.m.

BOOST_COMP_INTEL is set to 0, which means that [ predef-require "BOOST_COMP_INTEL" ] fails. __INTEL_COMPILER is set to 1500. BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) ) Thanks, John.

Show replies by date

John Maddock

12 Jul 12 Jul

8:54 a.m.

On 12/07/2015 09:42, John Maddock wrote:

...

BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) )

Thanks, John.

And another issue, I'm not sure if this is supposed to work or not but: [ predef-require "__ICL" ] always reports true regardless of the actual compiler used :( John.

Edward Diener

1:05 p.m.

On 7/12/2015 4:42 AM, John Maddock wrote:

...

BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) )

You can also see this on the regression tests for intel-linux ( http://www.boost.org/development/tests/develop/developer/output/GLIS-homo-im... ) where the compiler is identified as BOOST_COMP_EDG and both BOOST_COMP_GNUC_EMULATED and BOOST_COMP_INTEL_EMULATED are set to non-zero values.

Rene Rivera

1:20 p.m.

On Sun, Jul 12, 2015 at 7:05 AM, Edward Diener wrote:

...

On 7/12/2015 4:42 AM, John Maddock wrote:

...
BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) )

You can also see this on the regression tests for intel-linux ( http://www.boost.org/development/tests/develop/developer/output/GLIS-homo-im... ) where the compiler is identified as BOOST_COMP_EDG and both BOOST_COMP_GNUC_EMULATED and BOOST_COMP_INTEL_EMULATED are set to non-zero values.

OK.. But is that wrong? Is not the Intel compiler an EDG compiler, with the Intel back-end, that also mimics GCC? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

John Maddock

4 p.m.

On 12/07/2015 14:05, Edward Diener wrote:

...

On 7/12/2015 4:42 AM, John Maddock wrote:

...
BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) )

You can also see this on the regression tests for intel-linux ( http://www.boost.org/development/tests/develop/developer/output/GLIS-homo-im... ) where the compiler is identified as BOOST_COMP_EDG and both BOOST_COMP_GNUC_EMULATED and BOOST_COMP_INTEL_EMULATED are set to non-zero values.

It's not emulating the Intel compiler, it *is* the Intel compiler with version number 15.0, irrespective of whose front end they're using internally. John.

Rene Rivera

4:46 p.m.

On Jul 12, 2015 10:01 AM, "John Maddock" wrote:

...

On 12/07/2015 14:05, Edward Diener wrote:

...
On 7/12/2015 4:42 AM, John Maddock wrote:

...
BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) )

You can also see this on the regression tests for intel-linux (

http://www.boost.org/development/tests/develop/developer/output/GLIS-homo-im... ) where the compiler is identified as BOOST_COMP_EDG and both BOOST_COMP_GNUC_EMULATED and BOOST_COMP_INTEL_EMULATED are set to non-zero values.

...

...
It's not emulating the Intel compiler, it *is* the Intel compiler with version number 15.0, irrespective of whose front end they're using internally.

So it should be.. INTEL, EDG EMULATED, and GNUC EMULATED? Should it always be the case that EDG be marked as EMULATED?

Edward Diener

5:14 p.m.

On 7/12/2015 12:46 PM, Rene Rivera wrote:

...

On Jul 12, 2015 10:01 AM, "John Maddock" wrote:

...
On 12/07/2015 14:05, Edward Diener wrote:

...
On 7/12/2015 4:42 AM, John Maddock wrote:

...
BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) )

You can also see this on the regression tests for intel-linux (

http://www.boost.org/development/tests/develop/developer/output/GLIS-homo-im... ) where the compiler is identified as BOOST_COMP_EDG and both BOOST_COMP_GNUC_EMULATED and BOOST_COMP_INTEL_EMULATED are set to non-zero values.

...
...
It's not emulating the Intel compiler, it *is* the Intel compiler with version number 15.0, irrespective of whose front end they're using internally.

So it should be.. INTEL, EDG EMULATED, and GNUC EMULATED? Should it always be the case that EDG be marked as EMULATED?

Does it have to do with the order of the compilers you are checking ? If so, isn't the idea to at least check compilers which are not emulating other compilers first before you check compilers which could be emulating other compilers ? I don't believe the Intel compiler is emulating any other compiler, so if it were checked before EDG and GNUC the result should be correct. I haven't looked carefully at your predef logic for compilers but it appears to rely on the order in which your compiler header files are being included and from what I can see that order is purely alphabetic in compiler.h.

Rene Rivera

5:24 p.m.

On Jul 12, 2015 11:14 AM, "Edward Diener" wrote:

...

On 7/12/2015 12:46 PM, Rene Rivera wrote:

...
On Jul 12, 2015 10:01 AM, "John Maddock"

wrote:

...

...
...
On 12/07/2015 14:05, Edward Diener wrote:

...
On 7/12/2015 4:42 AM, John Maddock wrote:

...
BOOST_COMP_INTEL is set to 0, which means that

[ predef-require "BOOST_COMP_INTEL" ]

fails.

__INTEL_COMPILER is set to 1500.

BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) +

(((0)%100)*100000) +

...
...
...
((0)%100000) )

You can also see this on the regression tests for intel-linux (

http://www.boost.org/development/tests/develop/developer/output/GLIS-homo-im...

...
) where the compiler is identified as BOOST_COMP_EDG and both BOOST_COMP_GNUC_EMULATED and BOOST_COMP_INTEL_EMULATED are set to non-zero values.

...
...
It's not emulating the Intel compiler, it *is* the Intel compiler with

version number 15.0, irrespective of whose front end they're using internally.

So it should be.. INTEL, EDG EMULATED, and GNUC EMULATED? Should it always be the case that EDG be marked as EMULATED?

Does it have to do with the order of the compilers you are checking ? If so, isn't the idea to at least check compilers which are not emulating other compilers first before you check compilers which could be emulating other compilers ? I don't believe the Intel compiler is emulating any other compiler, so if it were checked before EDG and GNUC the result should be correct. I haven't looked carefully at your predef logic for compilers but it appears to rely on the order in which your compiler header files are being included and from what I can see that order is purely alphabetic in compiler.h.

Yes.. That's how it loosely works. I wasn't asking about how to implement it.. I was asking about correctness. As it's easy to change this.

John Maddock

5:21 p.m.

...

So it should be.. INTEL, EDG EMULATED, and GNUC EMULATED? Should it always be the case that EDG be marked as EMULATED?

Good question, we have a few different situations here: * The compiler vendor (Intel in this case). * Some other compiler they may be emulating (GCC or MSVC in Intel's case). * The compiler front-end used (EDG in this case). * The compiler back-end used (Intel in this case). A similar situation occurs with IBM's new Intel compiler, which uses the clang front-end but isn't really clang (it has some features clang doesn't have, some regular clang features are unimplemented, and the usual llvm back-end has been replaced by IBM's as far as I know). So given that there is no EDG compiler as such, and since we're certainly not emulating EDG, I would vote for something like BOOST_FRONTEND_EDG (or some similar variation). Not sure if this helps, John.

Rene Rivera

6:20 p.m.

On Jul 12, 2015 11:22 AM, "John Maddock" wrote:

...

...
So it should be.. INTEL, EDG EMULATED, and GNUC EMULATED? Should it

always

...

...
be the case that EDG be marked as EMULATED?

Good question, we have a few different situations here:

* The compiler vendor (Intel in this case). * Some other compiler they may be emulating (GCC or MSVC in Intel's case). * The compiler front-end used (EDG in this case). * The compiler back-end used (Intel in this case).

Right.. And I brought this issue up long ago :)

...

A similar situation occurs with IBM's new Intel compiler, which uses the clang front-end but isn't really clang (it has some features clang doesn't have, some regular clang features are unimplemented, and the usual llvm back-end has been replaced by IBM's as far as I know).

Yep.. And IIRC they unfortunately did not remove the llvm defs when they striped it out.

...

So given that there is no EDG compiler as such, and since we're certainly not emulating EDG, I would vote for something like BOOST_FRONTEND_EDG (or some similar variation).

It would be BOOST COMP EDG FRONTEND. As that follows general pattern of it being a part / variation of a compiler. So are EDG and clang the only frontends? Should we also have backbend definitions?

Peter Dimov

8 p.m.

Rene Rivera wrote:

...

So are EDG and clang the only frontends?

EDG is only a frontend; there is no EDG compiler. clang is apparently both a compiler and a frontend.

Peter Dimov

8:23 p.m.

...

Rene Rivera wrote:

...
So are EDG and clang the only frontends?

EDG is only a frontend; there is no EDG compiler. clang is apparently both a compiler and a frontend.

And, to answer your actual question, I can't think of any other frontends.

Hal Finkel

10:03 p.m.

----- Original Message -----

...

From: "Peter Dimov" To: boost@lists.boost.org Sent: Sunday, July 12, 2015 3:00:03 PM Subject: Re: [boost] [predef] Fails on Intel/win

Rene Rivera wrote:

...
So are EDG and clang the only frontends?

EDG is only a frontend; there is no EDG compiler. clang is apparently both a compiler and a frontend.

Technically, Clang is only a frontend, and LLVM is the compiler. Upstream Clang only supports one backend compiler: LLVM. It defines __llvm__ (and I hope that none of the non-LLVM forks continue to do this, but I'm not sure). As has been mentioned, there are a number of private forks of Clang used by various vendors, often with non-LLVM backends (as well as other changes/additions). Here are a few of the public ones of which I'm aware: Pathscale (http://www.pathscale.com/node/288) IBM (http://www-03.ibm.com/software/products/en/xlcpp-linux) Intel (for OS X) (http://llvm.org/devmtg/2014-04/PDFs/Posters/ClangIntel.pdf) -Hal

...

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

-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

Blower, Melanie

20 Jul 20 Jul

1:12 p.m.

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. 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 _boost/boost_1_57_0/boost/config/compiler/intel.hpp 2014-10-26 08:36:42.000000000 -0400 +++ _boost_patch/boost_1_57_0/boost/config/compiler/intel.hpp 2015-04-17 09:40:42.000000000 -0400 @@ -16,6 +16,26 @@ #include "boost/config/compiler/common_edg.hpp" +#if defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1500 +/* Intel(R) C++ Compiler (CQ358241 -- internal bug database reference) */ +/* 1) Add any Intel-specific generic pre-adjustments HERE */ +#ifdef __GNUC__ +/* 2) Add any Intel-specific gcc pre-adjustments HERE */ +#include "boost/config/compiler/gcc.hpp" +/* 3) Add any Intel-specific gcc post-adjustments HERE */ +#elif _MSC_VER +/* 4) Add any Intel-specific MS pre-adjustments HERE */ +#include "boost/config/compiler/visualc.hpp" +/* 5) Add any Intel-specific MS post-adjustments HERE */ Many of the boost compilation failures that we've received can be solved using this change to the configuration files. Our investigation starts like this: 1. preprocess the problematic source file with Intel configuration, compile with gcc, observe that gcc complains about the same source construct as the Intel compiler. 2. Likewise, preprocess problematic source file with gcc, compile with Intel, and see that the compilation succeeds. From this we conclude that there's a real problem in the boost source, but it's very difficult to track down. We'd rather have boost configured for our host compiler compatibility like this, and have bugs opened against the Intel compiler when boost finds problems that they would typically code around using compiler-specific configuration macros. -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Hal Finkel Sent: Sunday, July 12, 2015 6:03 PM To: boost@lists.boost.org Subject: Re: [boost] [predef] Fails on Intel/win ----- Original Message -----

...

From: "Peter Dimov" To: boost@lists.boost.org Sent: Sunday, July 12, 2015 3:00:03 PM Subject: Re: [boost] [predef] Fails on Intel/win

Rene Rivera wrote:

...
So are EDG and clang the only frontends?

EDG is only a frontend; there is no EDG compiler. clang is apparently both a compiler and a frontend.

...

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

-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

John Maddock

21 Jul 21 Jul

7:56 a.m.

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.

Blower, Melanie

2 p.m.

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@lists.boost.org] On Behalf Of John Maddock Sent: Tuesday, July 21, 2015 3:56 AM To: boost@lists.boost.org 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

John Maddock

22 Jul 22 Jul

5:08 p.m.

...

...
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,

This actually seems to work rather well - I've committed a fix to develop, but the new code is only enabled for Intel-15 and later as that's all I have installed at present. I've enabled SFINAE-expression support + binary literal support under MSVC as these seem to be working well there, and SFINAE-expression support enables a lot of very useful code. Linux GCC emulation I've left alone, even though there do appear to be several features supported beyond what the underlying GCC version supports. The compiler also seems to be ignoring -std= flags and just supporting everything always? Regards, John.

Blower, Melanie

27 Jul 27 Jul

7:22 p.m.

Re:

...

Linux GCC emulation I've left alone, even though there do appear to be several features supported beyond what the underlying GCC >version supports. The compiler also seems to be ignoring -std= flags and just supporting everything always?

No, the Intel compiler doesn't ignore the -std= flags. Is there a specific problem I could look at? Thanks and regards, Melanie -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, July 22, 2015 1:08 PM To: boost@lists.boost.org Subject: Re: [boost] [predef] Fails on Intel/win

...

...
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,

3345

Age (days ago)

3360

Last active (days ago)

List overview

Download

17 comments

6 participants

participants (6)

Blower, Melanie
Edward Diener
Hal Finkel
John Maddock
Peter Dimov
Rene Rivera