Several 3.0 draft issues

[jakub]

Just a couple of comments from what I found so far while starting to implement this for GCC:
2.5.1(p37, l7-l8) shouldn't it also allow pointer types? In C++, random access iterators are basically generalized version of pointers, so it would be weird if random access iterators are supported, but pointers are not.
In C there are no random access iterators in the base language, but if C++ supports pointers, then so should C
2.5.1(p38, l1) This paragraph doesn't seem to be clear enough for me for the cases where var is random access iterator or for collapse(2) and higher. When var is iterator, then the number of iterations can hardly
be computed in type of var after integral promotions. For iterators I'd say it should be computed in type of (b - var) (or (b - lb) ? ). If there are more associated
loops, then does it want to say that (b1 - lb1 + incr1) * (b2 - lb2 + incr2) ... * (bN - lbN + incrN) and any intermediate result thereof must be computed in type of outer most var (resp. (b1 - lb1))?
3.2.6(p110, l18) "if the any" should read "if any"
3.2.12(p118, l4) for C/C++, this function is declared to return int. What is the return value supposed to mean?
Appendix F there is no mention of the new default(firstprivate) clause in Fortran in the list of changes since 2.5, OpenMP 2.5 supported just default(private), default(shared) and default(none) in Fortran.

[lfm]

Thank you for the comments, Jakub. We will add them to the list and summarize our response after the public comment period.
-- Larry

[jakub]

Further comments/questions:

2.7 (p58, l31-36) doesn't list requirement that at most one untied clause can appear among #pragma omp task clauses. Do we really want to allow

Code: Select all

#pragma omp task untied untied untied

?
2.5.1 (p42, l5-6) could the definition of perfect nesting be more precise? E.g. can there be variable declarations in between the for-loop constructs,
or labels (of course that nobody can goto to them though), empty statements, or code that will never be executed? E.g. is:

Code: Select all

#pragma omp for collapse(4)
   for (int i = 0; i < 5; i++)
      {
         ;;;;               /* Are empty statements and/or several {} pairs ok?  */
         {
            int j;         /* Are variable declarations ok, as long as they don't have initializer?  */
            for (j = 0; j < 2; j++)
               {
                 int var = j + 1; /* What about variable declarations with initializers?  At least this smells like `code'.  */
unused_label: ;      /* Unused labels are ok too?  */
                 if (0) baz (0);   /* Code that won't be ever executed?  */
                 for (int k = 0; k < 2; k++)
                     for (int l = 0; l < 1; l++)
                        bar (i, j, k, l, var);
               }
          }
      }


valid?

[lfm]

Jakub:

Thank you, more good comments, to be added to the list.

-- Larry

[jakub]

Another small nit:
2.9.1.1 (p75, l25) says that loop iteration vars can be explicitly specified in task's private, firstprivate, shared and reduction clauses. But 2.7 (p57) doesn't allow reduction clause on the task construct.

[Randy]

(p18, l12) • Appendix F: Changes from Version 2.5 to Version 3.0Please cancel my.........subscription to playboy?

[SlowTurtle]

It would be nice if there is a short section to specify how to write a single OpenMP directive in multiple lines.

Often, I need to add many private variables in a single OpenMP directive; therefore, the line becomes too long.
I need to chop it into several lines for printing on the paper and for easy reading.

Search on the Web, I found that to continue a single OpenMP directive in multiple lines, I'll need to add a back slash at the end of the line for C and C++.
But this feature was never talked about in the OpenMP 2.5.

I am hoping that the OpenMP 3.0 will talk about this minor but convenient feature.

[lfm]

Thank you for your comment. Backslash line continuation is a feature of the C language and is the way that #pragmas are normally continued, so we didn't feel that it would be appropriate to explain it in the OpenMP specification. It would certainly be useful material for a book or a tutorial.

-- Larry

[jakub]

In A.26.1c example std::vector and std::vector::iterator are used. But std::vector is a template rather than a class, so perhaps
std::vector<int> and std::vector<int>::iterator (or any other type as template parameter) should be used instead, and maybe
#include <vector> wouldn't hurt.

[jakub]

I know it is past deadline, but though I'll mention it anyway:
In 2.9.2 (p77, l27), the "where list is a comma-separated list of file-scope, namespace-scope, or static block-scope variables that do not have incomplete types."
wording hasn't been adjusted for the new support of threadprivate static class members. So IMHO after variables should be inserted "or static class members ".
Or are threadprivate static class members allowed to have incomplete type if it is the type of the class being currently defined? Say is
struct A
{
int i;
static A j;
#pragma omp threadprivate (j)
};

A A::j;

valid? Also, does #pragma omp threadprivate need to lexically follow the definition of the static class member? Say is
struct B
{
#pragma omp threadprivate (i)
static int i;
};
int B::i = 4;
valid or not? The restrictions say that all uses of the static class member must lexically follow the pragma.