Potential privacy infringement warning and openmp critical sections...

Potential privacy infringement warning and openmp critical sections...

I have a simple parallel openmp loop where I'm keeping the count of total processed items to report progress.

I'm getting a "potential privacy infringement" warning on variable "materialsProcessed".
The variable is indeed on the stack of the main thread, but access is synchronized using a critical directive.

Is this a false positive? Doesn't parallel inspector check the critical section pragma for checking the access pattern?

Or am I doing something wrong here? Sometimes it's easy to miss basic stuff :)


  int materialsProcessed = 0;

#pragma omp parallel for
  for (int i = 0; i < matMan->m_materials.m_count; i++)
    IDE_MATERIAL *material = matMan->m_materials[i];

    if (MaterialUsedOnObjects(material->m_handle))
#pragma omp critical
3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Well, reading the manual helps sometimes :)

It looks like I should link with Intel's openmp compatibility library or compile with Intel compiler as indicated in the release notes.

I didn't try it yet, but the problem is possibly related to using Microsoft's openmp implementation...

A suggestion:
How about issuing a warning on the next release of parallel inspector? A warning on the instrumentation phase or loading phase like: "I detected that you have linked with Micorosft openmp etc etc..." I think that it could be easily detected bu the inspector...


Using the Intel OpenMP compatibility library will suppress many false positives, but not this issue.

Intel Parallel Inspector issues the Potential PrivacyInfringment as a warning, not as an error, precisely because the technology in the tool is unable to tell if the issue is a problem in your code or not. We could turn the warning off - but then issues that are real would not be detected.

It does not matter that the access is in a critical section. Even if all you did was read that variable in the parallel section you would still get the same error. The issue is that you have multiple threads accessing a variable which is on the stack of a different thread.

This OpenMP code is correct, and you can safely supress this message.

We are evaluating your feature request for a warning regarding the MS OpenMP RTL - thanks for the suggestion.

Eric M

Leave a Comment

Please sign in to add a comment. Not a member? Join today