Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
7568 Discussions

OpenMP task depend pointers and structs

luiceur
Beginner
365 Views

I have got the following code:

int foo(pm_t* t_lb){
  int i;
  int BLOCK=4;
#pragma omp task default(none) shared(t_lb, BLOCK)  private(i) \
  depend (inout: t_lb->a)

  {
    for (i=1;i < 1000 + BLOCK; i++){
      
      t_lb->a =1.0f; 
    }
  }
}
int main(){
  
  pm_t* pm = NULL;
  pm = (pm_t*)calloc(1,sizeof(pm_t));
  
  
  pm->a = (double*)malloc(1000*sizeof(double));

#pragma omp parallel
  {
    /* Obtain thread number */
    int tid = omp_get_thread_num();
    printf("Hello World from thread = %d\n", tid);
    
#pragma omp master
    {
      foo(pm);
    }
  }
  
  return 0;
  
}

The structs:

typedef struct st pm_t;

struct st {  
  double* a;                 
  double* t_b;          
};

If this is compiled with Intel 17.0.2.174 I get:

tasks.c(10): error: invalid entity for this variable list in omp clause
    depend (inout: t_lb->a)

However I can compile it if I change the depend list to 

depend (inout: t_lb)

This happens with the Intel and GNU compilers but it does not produce an error or warning with the Cray compiler. 

I guess my question is, is this a bug in the Intel/GNU compilers or they just follow the OpenMP standard rules? 

 

0 Kudos
2 Replies
Judith_W_Intel
Employee
365 Views

http://stackoverflow.com/questions/4610656/why-is-class-member-variable-x-not-allowed-to-be-sharedx-...

This explains why data members are not allowed as OpenMP variables.

 

jimdempseyatthecove
Black Belt
365 Views

Judith,

With regard to the S.O. article, x was declared as member variable "int *x". In my opinion shared(x) should have identified x as member variable x ... with no compiler overhead. The compiler manages to do this with StackPointer->x, it should be just as easy to do this->x. Additionally "That is, they make it a function. Private variables are generally passed to this function and shared variables may be passed or be within the function's scope." The OpenMP generated function would be the same as an unnamed/internally named member function otherwise default(shared) would not work. I do not buy the committee's argument.

This said, I see a programmer's responsibility that the pointer x not be uncooperatively altered during execution of the parallel region.

Jim Dempsey

Reply