Several 3.0 draft issues

The public comment period closed January 31, 2008. This forum is now locked (read only).

Several 3.0 draft issues

Postby jakub » Fri Oct 26, 2007 3:49 am

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.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby lfm » Fri Oct 26, 2007 8:26 am

Thank you for the comments, Jakub. We will add them to the list and summarize our response after the public comment period.
-- Larry
lfm
 
Posts: 135
Joined: Sun Oct 21, 2007 4:58 pm
Location: OpenMP ARB

Re: Several 3.0 draft issues

Postby jakub » Wed Nov 14, 2007 9:27 am

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?
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby lfm » Thu Nov 15, 2007 2:49 am

Jakub:

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

-- Larry
lfm
 
Posts: 135
Joined: Sun Oct 21, 2007 4:58 pm
Location: OpenMP ARB

Re: Several 3.0 draft issues

Postby jakub » Fri Nov 30, 2007 7:35 am

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.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby Randy » Thu Dec 13, 2007 2:01 pm

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

Spec for multiple lines in a single OpenMP directive

Postby SlowTurtle » Thu Dec 20, 2007 8:49 am

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.
SlowTurtle
 
Posts: 1
Joined: Thu Dec 20, 2007 8:12 am
Location: A pond near the Potomac River, Washingon, DC, USA

Re: Several 3.0 draft issues

Postby lfm » Thu Dec 20, 2007 9:59 am

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
lfm
 
Posts: 135
Joined: Sun Oct 21, 2007 4:58 pm
Location: OpenMP ARB

Re: Several 3.0 draft issues

Postby jakub » Thu Jan 31, 2008 4:22 pm

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
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby jakub » Tue Feb 26, 2008 5:08 am

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.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Next

Return to Draft 3.0 Public Comment

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest