[llvm-bugs] [Bug 40397] New: OpenMP: default(none) implementation is standard-incompliant.

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Jan 21 23:52:47 PST 2019


            Bug ID: 40397
           Summary: OpenMP: default(none) implementation is
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Clang Compiler Support
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: llvm-bugs at lists.llvm.org

Initially was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967


void foo(int *x);

void test1(int * const begin, const int len) {
#pragma omp parallel default(none)
#pragma omp for
for(int x = 0; x < len; x++)
    foo(begin + x);

gcc 8.2, clang trunk is ok with that code.
gcc trunk says:

<source>: In function 'void test1(int*, int)':
<source>:5:9: error: 'len' not specified in enclosing 'parallel'
    5 | #pragma omp for
      |         ^~~
<source>:4:9: error: enclosing 'parallel'
    4 | #pragma omp parallel default(none)
      |         ^~~
<source>:7:9: error: 'begin' not specified in enclosing 'parallel'
    7 |     foo(begin + x);
      |         ^~~~~
<source>:4:9: error: enclosing 'parallel'
    4 | #pragma omp parallel default(none)
      |         ^~~
Compiler returned: 1

Since 'default(none)' is specified, i fail to see how they are not specified..

I'm also not really seeing the reasoning in the openmp 4.0 " default
Did this change in newer openmp versions?

Reply from Jakub Jelinek:

It indeed changed, already in OpenMP 4.0 actually, but I've been long hoping
that the change will be reverted in later OpenMP standards, in the end that is
not what is going to happen.
OpenMP 3.1 and earlier had:
"Variables with const-qualified type having no mutable member are shared."
among the predetermined data sharing of variables for C/C++, and
"Variables with const-qualified type having no mutable member may be listed in
C/C++ firstprivate clause."
as an exception to the rule that variables with predetermined data sharing may
not be specified in OpenMP data sharing clauses.
That is gone in OpenMP 4.0, these variables are not predetermined anymore, so
with default(none) they must be specified in data sharing clauses if they are
referenced in the region.  They can be specified in both shared and
firstprivate clauses now, e.g. lastprivate/reduction/linear aren't suitable
because they all need to write into the variable.  If you want to write code
that will work with both OpenMP 3.1 and OpenMP 4.0+ (including 5.0, which
hasn't changed in this area), you need to use firstprivate(begin, len) in your
example, that used to be valid in OpenMP 3.1 due to the above exception and
keeps to be valid now.

I've asked the ifort/clang maintainers about why they keep violating the
standard, but haven't heard back from them.  And I must say I was trying hard
to readd the above rule + exception, but haven't succeeded.

The exact wording why the above needs to be refused is:
"The default(none) clause requires that each variable that is referenced in the
construct, and that does not have a predetermined data-sharing attribute, must
have its data-sharing attribute explicitly determined by being listed in a
data-sharing attribute clause."
As it is not predetermined (anymore) and is not explicitly determined either,
it violates the requirement above.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190122/f8861a45/attachment-0001.html>

More information about the llvm-bugs mailing list