[Flang][OpenMP] Compilation error when declarations within threadprivate directive and explicit declarations

[ohno-fj]

Version of flang-new : 20.0.0(3496245ed3d0b4d24444260da77dcdb93512fb5a/AArch64

Variables defined with threadprivate directive and explicit declaration result in a compilation-time error.
When threadprivate directive is removed, the compilation succeeds

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

snggy156_.f90:

subroutine s1
  integer omp_get_thread_num
  save p1,x1
!$omp threadprivate (p1)
!$omp threadprivate (x1)
  integer x1
  procedure(ss1),pointer::p1
  interface
     subroutine ss1(i)
     end subroutine ss1
     subroutine ss2(i)
     end subroutine ss2
  end interface
!$omp parallel private(k)
  if (omp_get_thread_num() ==1) then
     p1=> ss1
  else
     p1=> ss2
  end if
  call p1(k)
  if (omp_get_thread_num() ==1) then
     if (k/=1) print *,101
  else
     if (k/=2) print *,102
  endif
!$omp end parallel
end subroutine s1

program main
  call s1
  print *,'pass'
end program main

subroutine ss1(i)
  i=1
end subroutine ss1

subroutine ss2(i)
  i=2
end subroutine ss2

$ flang-new -fopenmp snggy156_1.f90
error: Semantic errors in snggy156_.f90
./snggy156_.f90:6:11: error: The type of 'x1' has already been implicitly declared
    integer x1
            ^^
./snggy156_.f90:3:11: Implicit declaration of 'x1'
    save p1,x1
            ^^
./snggy156_.f90:7:27: error: The interface for procedure 'p1' has already been declared
    procedure(ss1),pointer::p1
                            ^^
./snggy156_.f90:3:8: Implicit declaration of 'p1'
    save p1,x1
         ^^
$

$ gfortran -fopenmp snggy156_.f90; ./a.out
 pass
$

$ ifort -qopenmp -diag-disable=10448 snggy156_.f90
snggy156_.f90(6): error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name.
  [X1]
  integer x1
----------^
snggy156_.f90(7): error #6406: Conflicting attributes or multiple declaration of name.   [P1]
  procedure(ss1),pointer::p1
--------------------------^
snggy156_.f90(16): error #6424: This name has already been used as an external subroutine name.   [SS1]
     p1=> ss1
----------^
snggy156_.f90(16): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET at
tribute, or it must have the POINTER attribute.   [SS1]
     p1=> ss1
----------^
snggy156_.f90(18): error #6424: This name has already been used as an external subroutine name.   [SS2]
     p1=> ss2
----------^
snggy156_.f90(18): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET at
tribute, or it must have the POINTER attribute.   [SS2]
     p1=> ss2
----------^
snggy156_.f90(20): error #6419: This scalar name is invalid in this context.   [P1]
  call p1(k)
-------^
compilation aborted for snggy156_.f90 (code 1)
$

[llvmbot]

@llvm/issue-subscribers-openmp

Author: None (ohno-fj)

``` Version of flang-new : 20.0.0(3496245/AArch64 ```

Variables defined with threadprivate directive and explicit declaration result in a compilation-time error.
When threadprivate directive is removed, the compilation succeeds

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

snggy156_.f90:

subroutine s1
  integer omp_get_thread_num
  save p1,x1
!$omp threadprivate (p1)
!$omp threadprivate (x1)
  integer x1
  procedure(ss1),pointer::p1
  interface
     subroutine ss1(i)
     end subroutine ss1
     subroutine ss2(i)
     end subroutine ss2
  end interface
!$omp parallel private(k)
  if (omp_get_thread_num() ==1) then
     p1=> ss1
  else
     p1=> ss2
  end if
  call p1(k)
  if (omp_get_thread_num() ==1) then
     if (k/=1) print *,101
  else
     if (k/=2) print *,102
  endif
!$omp end parallel
end subroutine s1

program main
  call s1
  print *,'pass'
end program main

subroutine ss1(i)
  i=1
end subroutine ss1

subroutine ss2(i)
  i=2
end subroutine ss2

$ flang-new -fopenmp snggy156_1.f90
error: Semantic errors in snggy156_.f90
./snggy156_.f90:6:11: error: The type of 'x1' has already been implicitly declared
    integer x1
            ^^
./snggy156_.f90:3:11: Implicit declaration of 'x1'
    save p1,x1
            ^^
./snggy156_.f90:7:27: error: The interface for procedure 'p1' has already been declared
    procedure(ss1),pointer::p1
                            ^^
./snggy156_.f90:3:8: Implicit declaration of 'p1'
    save p1,x1
         ^^
$

$ gfortran -fopenmp snggy156_.f90; ./a.out
 pass
$

$ ifort -qopenmp -diag-disable=10448 snggy156_.f90
snggy156_.f90(6): error #<!-- -->6415: This name cannot be assigned this data type because it conflicts with prior uses of the name.
  [X1]
  integer x1
----------^
snggy156_.f90(7): error #<!-- -->6406: Conflicting attributes or multiple declaration of name.   [P1]
  procedure(ss1),pointer::p1
--------------------------^
snggy156_.f90(16): error #<!-- -->6424: This name has already been used as an external subroutine name.   [SS1]
     p1=&gt; ss1
----------^
snggy156_.f90(16): error #<!-- -->6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET at
tribute, or it must have the POINTER attribute.   [SS1]
     p1=&gt; ss1
----------^
snggy156_.f90(18): error #<!-- -->6424: This name has already been used as an external subroutine name.   [SS2]
     p1=&gt; ss2
----------^
snggy156_.f90(18): error #<!-- -->6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET at
tribute, or it must have the POINTER attribute.   [SS2]
     p1=&gt; ss2
----------^
snggy156_.f90(20): error #<!-- -->6419: This scalar name is invalid in this context.   [P1]
  call p1(k)
-------^
compilation aborted for snggy156_.f90 (code 1)
$

[llvmbot]

@llvm/issue-subscribers-flang-frontend

Author: None (ohno-fj)

``` Version of flang-new : 20.0.0(3496245/AArch64 ```

Variables defined with threadprivate directive and explicit declaration result in a compilation-time error.
When threadprivate directive is removed, the compilation succeeds

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

snggy156_.f90:

subroutine s1
  integer omp_get_thread_num
  save p1,x1
!$omp threadprivate (p1)
!$omp threadprivate (x1)
  integer x1
  procedure(ss1),pointer::p1
  interface
     subroutine ss1(i)
     end subroutine ss1
     subroutine ss2(i)
     end subroutine ss2
  end interface
!$omp parallel private(k)
  if (omp_get_thread_num() ==1) then
     p1=> ss1
  else
     p1=> ss2
  end if
  call p1(k)
  if (omp_get_thread_num() ==1) then
     if (k/=1) print *,101
  else
     if (k/=2) print *,102
  endif
!$omp end parallel
end subroutine s1

program main
  call s1
  print *,'pass'
end program main

subroutine ss1(i)
  i=1
end subroutine ss1

subroutine ss2(i)
  i=2
end subroutine ss2

$ flang-new -fopenmp snggy156_1.f90
error: Semantic errors in snggy156_.f90
./snggy156_.f90:6:11: error: The type of 'x1' has already been implicitly declared
    integer x1
            ^^
./snggy156_.f90:3:11: Implicit declaration of 'x1'
    save p1,x1
            ^^
./snggy156_.f90:7:27: error: The interface for procedure 'p1' has already been declared
    procedure(ss1),pointer::p1
                            ^^
./snggy156_.f90:3:8: Implicit declaration of 'p1'
    save p1,x1
         ^^
$

$ gfortran -fopenmp snggy156_.f90; ./a.out
 pass
$

$ ifort -qopenmp -diag-disable=10448 snggy156_.f90
snggy156_.f90(6): error #<!-- -->6415: This name cannot be assigned this data type because it conflicts with prior uses of the name.
  [X1]
  integer x1
----------^
snggy156_.f90(7): error #<!-- -->6406: Conflicting attributes or multiple declaration of name.   [P1]
  procedure(ss1),pointer::p1
--------------------------^
snggy156_.f90(16): error #<!-- -->6424: This name has already been used as an external subroutine name.   [SS1]
     p1=&gt; ss1
----------^
snggy156_.f90(16): error #<!-- -->6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET at
tribute, or it must have the POINTER attribute.   [SS1]
     p1=&gt; ss1
----------^
snggy156_.f90(18): error #<!-- -->6424: This name has already been used as an external subroutine name.   [SS2]
     p1=&gt; ss2
----------^
snggy156_.f90(18): error #<!-- -->6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET at
tribute, or it must have the POINTER attribute.   [SS2]
     p1=&gt; ss2
----------^
snggy156_.f90(20): error #<!-- -->6419: This scalar name is invalid in this context.   [P1]
  call p1(k)
-------^
compilation aborted for snggy156_.f90 (code 1)
$

[luporl]

The problem is the declaration of a variable type after !$omp threadprivate, as the reduced test below shows:

subroutine s1
  save x1
  !$omp threadprivate (x1)
  integer x1
end subroutine

Gfortran allows it, while ifort and ifx don't. I couldn't find anything in OpenMP standard that allows or disallows it.
Do we want to support this kind of declaration on flang?

[luporl]

AFAIU, what happens is that x1 in !$omp threadprivate (x1) is handled as a data reference and its type is determined at this moment. In the example above, implicit rules are used and the resulting type is REAL.
When integer x1 is processed, an error occurs, as the type was already implicitly declared as REAL.

A change that could be made to support declarations with multiple parts, where !$omp threadprivate is not the last part, would be to skip resolving threadprivate variable names in ResolveSpecificationParts phase and only resolve them later, in ResolveOmpParts phase.

The changes below are enough to support the previous example:

diff --git a/flang/lib/Semantics/resolve-directives.cpp b/flang/lib/Semantics/resolve-directives.cpp
index 4aecb8b8e7b4..34b3b37e2900 100644
--- a/flang/lib/Semantics/resolve-directives.cpp
+++ b/flang/lib/Semantics/resolve-directives.cpp
@@ -2319,6 +2319,9 @@ void OmpAttributeVisitor::ResolveOmpObject(
           [&](const parser::Designator &designator) {
             if (const auto *name{
                     semantics::getDesignatorNameIfDataRef(designator)}) {
+              if (!name->symbol) {
+                name->symbol = ResolveName(name);
+              }
               if (auto *symbol{ResolveOmp(*name, ompFlag, currScope())}) {
                 auto checkExclusivelists =
                     [&](const Symbol *symbol1, Symbol::Flag firstOmpFlag,
@@ -2429,6 +2432,9 @@ void OmpAttributeVisitor::ResolveOmpObject(
             }
           },
           [&](const parser::Name &name) { // common block
+            if (!name.symbol) {
+              name.symbol = ResolveName(&name);
+            }
             if (auto *symbol{ResolveOmpCommonBlockName(&name)}) {
               if (!dataCopyingAttributeFlags.test(ompFlag)) {
                 CheckMultipleAppearances(
diff --git a/flang/lib/Semantics/resolve-names.cpp b/flang/lib/Semantics/resolve-names.cpp
index ec8f854f64d1..a37d00291866 100644
--- a/flang/lib/Semantics/resolve-names.cpp
+++ b/flang/lib/Semantics/resolve-names.cpp
@@ -1489,6 +1489,9 @@ public:
   void Post(const parser::OmpEndCriticalDirective &) {
     messageHandler().set_currStmtSource(std::nullopt);
   }
+  bool Pre(const parser::OpenMPThreadprivate &) {
+    return false;
+  }
 };

 bool OmpVisitor::NeedsScope(const parser::OpenMPBlockConstruct &x) {

However, OmpAttributeVisitor::ResolveName performs only a simple symbol lookup and doesn't handle more complex specifications, such as structure elements, that are handled by DeclarationVisitor::ResolveDesignator. Exporting it somehow to OmpAttributeVisitor would be a bigger change, not worth trying before further discussions.

[luporl]

With #112414 merged, the semantic errors don't occur anymore.

There is still an error in lowering, that seems to be related to the usage of threadprivate with procedure pointers:

error: loc("/Users/leandro.lupori/current/test.f90":1:1): 'omp.threadprivate' op failed to verify that all of {sym_addr, tls_addr} have same type
error: Lowering to LLVM IR failed
error: loc("/Users/leandro.lupori/current/test.f90":1:1): cannot be converted to LLVM IR: missing `LLVMTranslationDialectInterface` registration for dialect for op: func.func
error: failed to create the LLVM module

As this is the same issue reported on #100950, I'm closing this one.