The OpenMP ARB plans to integrate the Technical Report on directives for attached accelerators, as well as more new features, in a final Release Candidate 2, to appear sometime in the first Quarter of 2013, followed by the finalized full 4.0 API specifications soon thereafter.
The 4.0 Release Candidate API specifications (4.0RC1) and the Technical Report (TR1) PDFs can be downloaded from http://openmp.org/wp/openmp-specifications/ and discussed in this forum.
Technical Report 1 - discuss here too.
Forum rules
This forum is now closed.
This forum is now closed.
Technical Report 1 - discuss here too.
Richard Friedman rchrd -at- rchrd -dot- com
openmp.org webmaster
openmp.org webmaster
Re: Technical Report 1 - discuss here too.
Regarding the Accelerator TR:
* It think the document lacks (nonnormative) examples. They would help a lot to understand the document and to clarify some intentions.
* It is rather unclear to me which constructs are allowed for the target. Especially, I am thinking of procedure/functions calls within that section, where a suitable target function exists (or not exists). And in terms of diagnostic, I think it would be helpful to be able to pass some of this information via header files or for Fortran in module files and interface blocks to allow for good compile-time diagnostic. I think at least the syntax has to be defined otherwise it cannot be reliably used across multiple compilers.
* It think the document lacks (nonnormative) examples. They would help a lot to understand the document and to clarify some intentions.
* It is rather unclear to me which constructs are allowed for the target. Especially, I am thinking of procedure/functions calls within that section, where a suitable target function exists (or not exists). And in terms of diagnostic, I think it would be helpful to be able to pass some of this information via header files or for Fortran in module files and interface blocks to allow for good compile-time diagnostic. I think at least the syntax has to be defined otherwise it cannot be reliably used across multiple compilers.
Re: Technical Report 1 - discuss here too.
Follow up to my own comment/question.
Shouldn't there be a recommendation in the spec that calls which would lead to code which cannot be run on the target will be diagnosed by the compiler [(optional) warning]? I assume that then the whole target region is then turned into a non-target version.
Are there restrictions? Namely, does it need to be in the same file (translation unit) for C? And for Fortran, in the scope (allowing for a module in a different file)? Is access to a global or static/SAVE variable, volatile variables possible? Does the procedure have to be pure (pure attribute in Fortran)?. Are there restrictions on calling (standard) library functions / INTRINSIC procedures?The declare target construct can be applied to a function (C, C++ and Fortran) or a subroutine (Fortran) to enable the creation of a device specific version that can be called from a target region.
Shouldn't there be a recommendation in the spec that calls which would lead to code which cannot be run on the target will be diagnosed by the compiler [(optional) warning]? I assume that then the whole target region is then turned into a non-target version.