When within the visible section of an !$omp parallel region using default(none), the compiler objects to performing an associate, with an associate name that is not named as private, firstprivate, shared, ...
While I can see a potential need to have private, firstprivate, shared declaration for an associated name, the lexical problem is where is then (functionally suitable) appropriate position to place the OpenMP clause. Seeing that the associate name may not be defined at the point of the !$omp parallel region, or at the point of the !$omp do, it is only known at the point of the ASSOCIATE. To complicate the matter, the associated name, can be an existing name with different type, rank, and/or shape. IOW, it may be improper (dangerous) to place the (a) future associated name at the point of the !$omp parallel region, or at the point of the !$omp do. Example, a formerly used name being a scalar, subsequently used as an associated name of an array. IOW now used as an array descriptor. In this case, especially when shared within (as opposed to across) the parallel region, this could cause corruption of the following declared privates of the region of loop.
Sorry for the long winded explanation.
It would appear that the proper place to specify the !$omp private/shared/... would be immediately preceding the associate statement.
Is there any comments on this.
Hi Jim, I hopefully have partially understand what you've written ( referring to the Fortran ASSOCIATE intrisic). In an older thread we discussed the used of associate in an OpenMP parallel region. In my code I was not able to solve the issues with the associate(ted) objects and I did abondomed ASSOCIATE totally in OpenMP regions. Since the OpenMP specifications 4.5 and 5.0 do not prohibit the use of ASSOCIATE it is still unclear whether one can use it savely or not.
I appreciate your suggestion of adding a directive directly in front of an ASSOCIATE, if that would enable a save use in a standarized way.
ps: Again I would be very happy, if Intel could provide a list with all supported Fortran feature in an OpenMP region (link to other thread).
Hi Jim, have you plans to make a proposal regarding this topic or was it more thinking aloud? I would be interested to know, if there is an update.