I am aware that this issue has been raised before however the resolutions posted in those specific threads have not aided in my case.
I am getting the following openmp error for a parallel for loop directive.
domain.cpp(902): error: invalid entity for this variable list in omp clause
The offending code can be seen below:
#pragma omp parallel for schedule(static) private(ib) shared(nblk,sq,saux,srhs,slhs,
for( ib=0;ib<nblk;ib++ )
blks[ib]->iflx( nq, sq, saux, srhs, slhs, fld);
blks is an array holding BLOCK objects within a block-structured grid whilst nq, sq, saux, srhs, slhs are arrays declared as data members for a Domain class. I have updated to the latest icpc compiler with no avail (icpc (ICC) 15.0.0 20140723)
Does anyone have the faintest of idea what the problem might be?
Thank you in advance for your time and consideration.
What happens with
#pragma omp parallel for schedule(static) private(ib) // shared(nblk,sq,saux,srhs,slhs,fld)
IOW using default shared for listed items.
What I suspect is one of nblk,sq,saux,srhs,slhs,fld is undefined.
Thank you for your reply. I had tried it before and forgot to mention the fact that without the explicit shared clause, the application compiles and runs successfully. I have tried to alternate and only include one or two members into the shared clause such as saux or sq but that still doesn't work. I am aware that if you leave out default(none), these elements will be automatically shared but then why does it have an issue when I try to tell it explicitly to do this via a clause?
Furthermore, are there any performance penalties between explicitly declaring data structures as shared compared to the implicit option.
Also, the variables passed are not undefined as I previously checked all of the above via gdb.
There should be no performance difference between default(none) and shared(...).
A few things to look at (not determinable by your sketch code):
Are any of the variables in your shared list thread private?
Is your #pragma omp parallel... inside a parallel region?
I tried variations of placing everything within a #pragma omp parallel and setting the shared scope in there followed by the pragma omp for scheduling to fusing all directives together and I still get the same compiler error.
I'm happy if you think the performance is the same. My main concern was that the compiler might have been able to apply further optimisations if the data scoping was given to it explicitly. I am still at odds as to why this is happening though.
does the same case build with GCC? Also, you may just check one by one to see which variable caused the issue, example, test with:
#pragma omp parallel for schedule(static) private(ib) shared(nblk)
#pragma omp parallel for schedule(static) private(ib) shared(sq)
To check which variable cause the issue and you may try to generate a test case for us to fix if it is a bug. :)