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

OpenMP task depend pointers and structs


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
  return 0;

The structs:

typedef struct st pm_t;

struct st {  
  double* a;                 
  double* t_b;          

If this is compiled with Intel 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

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


0 Kudos
Black Belt


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

0 Kudos