ICC should not generate warning about "#pragma omp ..." when OMP is disabled

[Marián__VooDooMan__M]

Greetings,

ICC 13.0, MSVC 2010

When I disable OpenMP support of ICC, it is displaying bunch of warnings in build log like:

[bash]c:\path/to/file.h(439): warning #161: unrecognized #pragma #pragma omp sections ^[/bash] this warning is abusing me.

I have many OMP pragma's in the code, and when I do benchmarks without OpenMP support versus with OpenMP support, I might miss some IMPORTANT warning hidden somewhere in thousands of these warnings.

I don't want to pass to compiler "/Qwd161" do disable warning about invalid pragma's, since I am afraid of typo in other pragma's, so I would expect warning in this case as non-false positive.

Any objections? This is just a suggestion. TIA!

[ILevi1]

Why don't you just compile with openmp serial code? That way all omp pragmas will still be valid, just the code will be executed sequentially.

If you don't like that idea for some reason you can try doing something like this:
[cpp]#ifdef _OPENMP #define OMP(x) omp x #else #define OMP(x) message("") #endif [/cpp]

[Marián__VooDooMan__M]

Quoting Igor Levicki

Why don't you just compile with openmp serial code? That way all omp pragmas will still be valid, just the code will be executed sequentially.

If you don't like that idea for some reason you can try doing something like this:

- collapse sourceview plaincopy to clipboardprint?

1. #ifdef_OPENMP
2. #defineOMP(x)ompx
3. #else
4. #defineOMP(x)message("")
5. #endif

[cpp]#ifdef _OPENMP #define OMP(x) omp x #else #define OMP(x) message("") #endif [/cpp]

Ugly hack with preprocessor is rather a workaround then a serious solution, and it has adverse side effect of printing many empty lines into build log.

I don't want to switch it to serial code, because I'm afraid run-time linking OMP .dll might cause overhead, compared to completely turned off the OMP.

[TimP]

Not knowing whether by "switch it to serial" you mean setting OMP_NUM_THREADS=1, here's another option: link against libompstubs library. I doubt you could measure the associated startup time, and the stubs calls almost certainly are faster than the normal ones.

[Marián__VooDooMan__M]

Quoting Tim Prince

Not knowing whether by "switch it to serial" you mean setting OMP_NUM_THREADS=1, here's another option: link against libompstubs library. I doubt you could measure the associated startup time, and the stubs calls almost certainly are faster than the normal ones.

By sequential I meant in MSVS "Generate Sequential Code (/Qopenmp_stubs)", is this what you meant by "stubs" ? I don't care much about start-up time, but I am afraid of (possibly) creating unused thread by OpenMP library by using this option, which could affect running performance (I don't mind about start-up performance).

But some switch would be really sexy. Just like "ignore '#pragma omp' at all when OMP is not understood/turned on", w/o a warning, so I will need not to use switch to ignore warning, nor use preprocessor hacks, nor using "sequential OMP".

[TimP]

Yes, /QOpenmp_stubs will avoid creating threads for OpenMP.

[Brandon_H_Intel]

Unfortunately there isn't currently a clean way to do this, but I like the idea, so I've submitted a feature request to our front end team to create a different warning to explicitly diagnose unrecognized OpenMP pragmas separately.

[Marián__VooDooMan__M]

Quoting Brandon Hewitt (Intel)

Unfortunately there isn't currently a clean way to do this, but I like the idea, so I've submitted a feature request to our front end team to create a different warning to explicitly diagnose unrecognized OpenMP pragmas separately.

You mean when OpenMP support is disabled, it should generate for "#pragma omp ..." special warning (not one like in current implementation "unrecognised pragma"), but special warning like "OMP is disabled, ignoring #pragma omp" with its separate warning number? So one could easily disable only OMP warnings, but not ALL #pragma warnings? If so, I like the idea to have separate warning number for this.

[ILevi1]

As I said (and Tim confirmed), switching to serial OpenMP code will solve your problem.

If you disable warning you may forget to re-enable OpenMP later. I really don't see a need for special treatment here.

Finally, instead of using message("") like in my example you can use any other NOP construct that won't generate any code or add any empty lines.

[Marián__VooDooMan__M]

Igor Levicki wrote:

As I said (and Tim confirmed), switching to serial OpenMP code will solve your problem.

If you disable warning you may forget to re-enable OpenMP later. I really don't see a need for special treatment here.

Finally, instead of using message("") like in my example you can use any other NOP construct that won't generate any code or add any empty lines.

Greetings, which NOP pragma construct you would suggest? Because even "#pragma ivdep" is causing warning/remark message (since it is not in the front of a loop). I have came thru ICC documentation and maybe I am blind, but I don't see NOP pragma generating ***NONE*** output in the build log. And yes, switching OMP to generate serial code is remedy... but I guess it is just another JMP instruction into OpenMP DLL exported procedures table (or maybe followed by CALL instruction @ Windows) which could waste performance due to instruction cache flush. CALL maybe don't flush cache in all cases, but I guess JMP (as it is implemented on Windows) does indeed in any case (at least L1 cache ; maybe not L2 one).

[Marián__VooDooMan__M]

Brandon Hewitt (Intel) wrote:

Unfortunately there isn't currently a clean way to do this, but I like the idea, so I've submitted a feature request to our front end team to create a different warning to explicitly diagnose unrecognized OpenMP pragmas separately.

Greetings, this I would very appreciate. Thank you.

[Marián__VooDooMan__M]

Marián "VooDooMan" Meravý wrote:

Quote:

Brandon Hewitt (Intel)wrote:

Unfortunately there isn't currently a clean way to do this, but I like the idea, so I've submitted a feature request to our front end team to create a different warning to explicitly diagnose unrecognized OpenMP pragmas separately.

Greetings,

this I would very appreciate.

Thank you.

Or maybe some specific pragmas, like: #pragma warning( push ) # pragma warning( disable: <specific_number_of_ICC_warning/remark> ) // code #pragma warning( pop ) that I can use in the front of all header files, i.e. in the main, first *.h file of includes (in this case without "push" like -> ) #ifdef DISABLE_OMP_THINGIE_ETC # pragma warning( disable: <specific_number_of_ICC_warning/remark> ) #endif

[jimdempseyatthecove]

Try a variation on Igor's suggestion #ifndef _OPENMP #define omp comment #endif Jim Dempsey

[Brandon_H_Intel]

Hi Marián,

In version 14.0 of the compiler (available in Intel(R) C++ Composer XE 2013 SP1), we now have OpenMP* pragmas under their own warning number, like so:

$ icc -c test.cpp
test.cpp(2): warning #3180: unrecognized OpenMP #pragma
  #pragma omp parallel for
          ^

test.cpp(8): warning #161: unrecognized #pragma
  #pragma blh
          ^

So now you can use -diag-disable 3180 to disable these OpenMP*-specific pragmas. Let me know if that helps.

[Marián__VooDooMan__M]

@Brandon

it is impractical to always changes more than 1 option (enable/disable OMP) in MSVC IDE, when I am transitioning between various configuration profiles, when I am experimenting in regard of best CPU utilisation in the project.

My wish is to file a feature request.

Thank you.

[Marián__VooDooMan__M]

Marián "VooDooMan" Meravý wrote:

Quote:

Brandon Hewitt (Intel)wrote:

Unfortunately there isn't currently a clean way to do this, but I like the idea, so I've submitted a feature request to our front end team to create a different warning to explicitly diagnose unrecognized OpenMP pragmas separately.

Greetings, this I would very appreciate. Thank you.

Ouch, this thread is so old that I forgot in my previous post about above quote. I am sorry for that. Thanks again!