Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7956 Discussions

icpc 13.1.1.163 fails to compile a simple openMP source.

mikiya_fujii
Beginner
1,668 Views
Hi. I met an error to compile a simple openMP source with icpc 13.1.1.163 Build 20130313 although icpc 12.1.1.256 Build 20111011 works well. The error I met is following: openmpTes.cpp(4): error: syntax error in omp clause #pragma omp parallel for schedule(auto) ^ compilation aborted for openmpTes.cpp (code 2) Does this error mean a bug or my failures in install of 13.1.1? The source code (openmpTescpp) is following: #include int main() { #pragma omp parallel for schedule(auto) for(int i=0; i<5; i++){ } return 0; } The command I used is "$ icpc -openmp -O0 openmpTes.cpp" Information about my HD and OS: I'm using the icpc on the 64 bits Ubuntu 12.04 LTS. This Ubuntu is running on the Windows 7(Professional, 64-bit 6.1.7601, Service Pack 1) through the VMware(R) Player (4.0.4 build-744019). The processor of my laptop is "Intel Core i5-2520M CPU 2.50GHz*2". Welcome any comments Mikiya
0 Kudos
29 Replies
jimdempseyatthecove
Honored Contributor III
474 Views

Sergey,

Try cl with: #pragma omp parallel for schedule ( foobar )

Is cl quiet? If it is, then your report is no confirmation that schedule ( auto ) is supported by cl.

Jim Dempsey

0 Kudos
SergeyKostrov
Valued Contributor II
474 Views
I will try some time later. Jim, How should I declare the foobar variable?
0 Kudos
mikiya_fujii
Beginner
474 Views

>Sergey,
Thank you very much for your tests.
It's confirmed that, at least intel 13.1.0.149, schedule(auto) works well,
although I did not recieve the warning about #pragma...
BTW, I'm confusing related to which version of the openMP (3.0, 3.1, and/or 4.0) is used in the intel 13.1.1....

>TimP
Thank you very much for your valuable opinion.
>omp schedule(auto) is one of those facilities which were postponed
If so, unfortunately, should I wait a release of 14.0.0 or later...?
Or, schedule(runtime) and OMP_SCHEDULE seems to work fine for
what I want to do although many code in my appication are needed to be modified.

0 Kudos
TimP
Honored Contributor III
474 Views

I'm expecting to see a more authoritative tabulation of which OpenMP features appeared when.  It does appear that the 2013 update 2 and 3 compilers fairly well completed implementation of openmp 3.0.  I'll try my own schedule(auto) case to see if it works with update 3 or some combination of compiling with one and run time shared libraries of the other, of which I've already seen an instance.

0 Kudos
TimP
Honored Contributor III
474 Views

I ran a short benchmark including 3 exampes of schedule(auto) on a single architecture with all combinations of 2013 update 2,3, and beta compilers and the corresponding OpenMP libraries. It looks like schedule(auto) has worked well in such simple cases from update 2 on.

Object files made with update 3 didn't work with the other versions and had to be rebuilt.

0 Kudos
SergeyKostrov
Valued Contributor II
474 Views
>>... I'm confusing related to which version of the openMP (3.0, 3.1, and/or 4.0) is used in the intel 13.1.1... Take a look at properties of libiomp5md module or Release Notes for the version of Intel C++ compiler you're using. I don't think it has to be OpenMP version 3.0 or 4.0.
0 Kudos
TimP
Honored Contributor III
474 Views

The case under discussion here seems to be one where an OpenMP 3.0 capability wasn't fully implemented until some 2013 update.  collapse is another where important cases first worked in update 2. 

max/min reduction hasn't yet worked for me, even though the parallel version of it is in OpenMP 3.1.  An Intel presentation I saw recently claimed that it won't be standardized until OpenMP 4.0 is final.Of course, that's correct in reference to the #pragma omp simd reduction(max: which I don't think is available yet in any released or beta compiler.

In principle, #pragma omp parallel simd reduction could be used to simplify cases where it's currently best to write nested loops (outer parallel, inner vectorizable) with the best outer loop strategy differing according to the number of threads

#pragma omp simd safelen(32) is an OpenMP 4.0 feature which works better than the non-standard #pragma simd vectorlength, for the compiler versions which support it, which apparently go back to 2013 update 2.  I'm wondering whether to post this update in my public version.

My colleagues have agreed with me that there is justification for the confusion mentioned above, and I'm hoping for some documentation to shed light on it.  One would expect that interrogation of your OpenMP as to which version it supports would imply that all features of the reported version are present (at least to the extent that the application doesn't break when correct syntax is used).  That hasn't been true of all past versions. 

A full implementation of OpenMP 4.0 isn't advertised even for 14.0 compilers, but publicity for partial implementation to a greater extent than 2013 update 3 seems to be on the way.

0 Kudos
TimP
Honored Contributor III
474 Views

Oh, #pragma omp simd safelen is ignored for some target settings such as -msse4.1 but observed for -mavx.

0 Kudos
mikiya_fujii
Beginner
474 Views
Dear all, Thank you for your valuable discussions. I tried to compile the code by icpc 13.1.2 because I got a notification of release of the 13.1.2 in this morning Then, I succeeded to compile!!! So, I will use the 13.1.2 instead of 13.1.1. Thank you very much again Best regards, Mikiya
0 Kudos
Reply