Bug in omp firstprivate implementation

Bug in omp firstprivate implementation

I found a bug in the handling of OMP firstprivate data. (Using icc (ICC) 14.0.0 20130728 on linux) Here is a small example.

#include <vector>
using namespace std;
int main() {
   int i,k;
   int nr_NegSimp = 0;
   int nr_gen = 720;
   vector<int> zero_i(nr_gen);
   vector<int> subfacet(nr_gen);
   #pragma omp parallel for firstprivate(zero_i,subfacet) private(k) schedule(dynamic)
   for (i=0; i<nr_NegSimp;i++){
   return 0;

It gives an segfault (or up to number of threads many). The problem is the following: The vector is not correctly constructed, but the destructor is applied. This happens only when the loop is executed zero times (as in this example).

It is possible, that it was introduced in the fix for this bug http://software.intel.com/en-us/forums/topic/280462 since it seems to not appear in the windows version from 2011. In that version I found another bug in the firstprivate handling (see http://software.intel.com/en-us/forums/topic/285488).

I wanted to create a support ticked, but the system somehow does not allow me to choose the affected software.

7 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

I should add, that the problem only occurs when compiling with OpenMP (-fopenmp).

Fichiers joints: 

Fichier attachéTaille
Télécharger firstprivate2.cpp319 octets

Hi Christof,

I've entered this issue to our problem-tracking database.  Will let you know when I have an update regarding it.


Thank you.

In the meantime I was able to create a ticket at the support to.

What happens with:

#pragma omp parallel firstprivate(zero_i,subfacet) private(k) schedule(dynamic)
  #pragma omp for
  for (int i=0; i<nr_NegSimp;i++){

Jim Dempsey


Hi Jim,

yes that works fine. Exept that the schedule has to be specified at the for pragma, not the parallel.

Also maybe interesting is that it only happens with FIRSTprivate, not with just private. I guess the copying is not performed correctly in this case.

I have already eliminated the problem in my code. I just wanted to report the problem, since it clearly is a bug.

update to this issue. it has been fixed in update 2.

you can download the latest update 2 from the Intel Registration Center or the evaluation page.



Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui