- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This explains why data members are not allowed as OpenMP variables.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page