OPENMP version visible to pre-processor

[TimP]

According to Chapman, Yost, Van der Paas "Using OpenMP" p 47, OpenMP standard specifies ability to determine which OpenMP version is in effect by pre-processor macro, e.g.

#if defined _OPENMP && _OPENMP >= 200711

// OpenMP 3.1 is implemented; can use e.g. omp parallel reduction(max: )

#else

// need workaround for old compilers such as MSVC or RedHat 5/6 gcc

#endif

This appears to work with ICL.  On linux, however, icc takes _OPENMP from gcc, so such a macro will prevent icc from using OpenMP 3.1 unless a current gcc (newer than supported in RedHat/CentOS 6) is on PATH.

The situation worsens with the partial implementation of OpenMP 4.0.  Even with gcc versions which implement more of 4.0 than icc does, we have available only _OPENMP >= 200711 to signify support for 3.1 and maybe parts of 4.0.

I'm not expecting acceptable solutions with autoconf or the like to deal with this, but I would like to know if there is a supported method to know the difference between gcc and icc, other than use of __INTEL_COMPILER version numbers.  I've been able to cut back on use of gcc version numbers, but I fear that may be only temporary.

I was hoping to submit a problem report, but I confirmed that I am still excluded from submitting reports, since 10 weeks ago.

[Feilong_H_Intel]

Hi Tim,

I entered this issue to our problem-tracking database, as a feature request.  I'll let you know once I have an update.

Regarding your access to new IPS, please submit an issue at http://software.intel.com/en-us/forums/intel-software-development-products-download-registration-licensing.  A support engineer will look into your IPS access issue.

Thanks.

[TimP]

I'm hoping to resolve this by the following scheme:

#ifdef _OPENMP

#include <omp.h>

#if defined __INTEL_COMPILER && __INTEL_COMPILER_BUILD_DATE >= 20130607 && _OPENMP < 201107

#define _OPENMP 201107

#endif

#endif

I don't know the first icc build date which should have introduced full OpenMP 3.1 support, but that build date seems to incorporate the best reliability so far.

[jimdempseyatthecove]

TimP,

Good suggestion, minor ommission of "#undef _OPENMP" in front of "#define _OPENMP 201107"

I think it would be better to "#define __OPENMP_VERSION 301"

Jim Dempsey

[TimP]

In case this is your point, I agree that we may need to invent something like __OPENMP_VERSION with more increments, in view of OpenMP 4 being implemented incrementally over a period of more than a year.  But I'm talking just about making _OPENMP work in a similar way between Windows and linux with Intel compilers, as the OpenMP standard leads us to expect.

It looks like gcc 4.9 will include #pragma omp simd reduction(max: )  (and min) which seem to be a year away for icc. icc already has ways to avoid the need for them in many cases, and I'm already making use of several omp simd things for both icc and gcc (demonstration benchmarks, not production).

As icc doesn't document which OpenMP 4 features are implemented in the current release (the compiler document covers a lot of future ones), this may be left to trial and error on the part of individual developers.

[Feilong_H_Intel]

icc 14.0 update 2 solves the problem.  Please see this:

$ icc -E -dM -openmp q.c|grep OPENMP
#define _OPENMP 201307

[Jeffrey_H_Intel]

"#undef _OPENMP" violates ISO C 7.1.3 and leads to an undefined program (http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier has the excerpt, since the full ISO C spec is not freely available except as a draft). Furthermore, only the compiler is allowed to use "__OPENMP_VERSION". Names beginning with two underscores or one underscore and a capital letter are reserved.

[jimdempseyatthecove]

>>  Furthermore, only the compiler is allowed to use "__OPENMP_VERSION". Names beginning with two underscores or one underscore and a capital letter are reserved.

While this is valid in the sense of the intent of the standards committee, it may be a practical necessity for a user with a version of the compiler that predates the implementation as intended by the standards committee. This said, CAUTION should be taken when making such (un)defines.

Jim Dempsey