[flang-commits] [flang] [flang][acc] Permit acc routine for specific name (PR #211386)

via flang-commits flang-commits at lists.llvm.org
Wed Jul 22 16:46:54 PDT 2026


llvmorg-github-actions[bot] wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-flang-openmp

Author: Razvan Lupusoru (razvanlupusoru)

<details>
<summary>Changes</summary>

After https://github.com/llvm/llvm-project/pull/211269 a generic interface name is rejected in acc routine. This PR relaxes this by allowing it when the interface name and the specific are the same - and attaches the information to the specific itself.

---
Full diff: https://github.com/llvm/llvm-project/pull/211386.diff


2 Files Affected:

- (modified) flang/lib/Semantics/resolve-directives.cpp (+15-9) 
- (modified) flang/test/Semantics/OpenACC/acc-routine-generic.f90 (+17-1) 


``````````diff
diff --git a/flang/lib/Semantics/resolve-directives.cpp b/flang/lib/Semantics/resolve-directives.cpp
index cb710cdbb4589..ddee66489f2df 100644
--- a/flang/lib/Semantics/resolve-directives.cpp
+++ b/flang/lib/Semantics/resolve-directives.cpp
@@ -1424,17 +1424,23 @@ bool AccAttributeVisitor::Pre(const parser::OpenACCRoutineConstruct &x) {
     }
     for (const auto &name : names) {
       if (Symbol * sym{ResolveFctName(name)}) {
-        Symbol &ultimate{sym->GetUltimate()};
+        Symbol *target{&sym->GetUltimate()};
         // OpenACC ties the named argument of a ROUTINE directive to a
-        // subroutine or function. A generic interface name is therefore not a
-        // valid target.
-        if (ultimate.has<GenericDetails>()) {
-          context_.Say(name.source,
-              "A generic interface name may not appear in an ACC ROUTINE clause: %s"_err_en_US,
-              name.source);
-        } else {
-          AddRoutineInfoToSymbol(ultimate, x);
+        // subroutine or function. A pure generic interface name is not a
+        // valid target. However, a generic may share its name with a specific
+        // procedure (common with interface bodies); in that case the name
+        // denotes the specific, not the generic.
+        if (auto *generic{target->detailsIf<GenericDetails>()}) {
+          if (Symbol * specific{generic->specific()}) {
+            target = &specific->GetUltimate();
+          } else {
+            context_.Say(name.source,
+                "A generic interface name may not appear in an ACC ROUTINE clause: %s"_err_en_US,
+                name.source);
+            continue;
+          }
         }
+        AddRoutineInfoToSymbol(*target, x);
       } else {
         context_.Say(name.source,
             "No function or subroutine declared for '%s'"_err_en_US,
diff --git a/flang/test/Semantics/OpenACC/acc-routine-generic.f90 b/flang/test/Semantics/OpenACC/acc-routine-generic.f90
index 79804843f0a23..9e48f72e0547a 100644
--- a/flang/test/Semantics/OpenACC/acc-routine-generic.f90
+++ b/flang/test/Semantics/OpenACC/acc-routine-generic.f90
@@ -1,8 +1,12 @@
 ! RUN: %python %S/../test_errors.py %s %flang_fc1 -fopenacc
 
-! A generic interface name is not a valid target of an OpenACC ROUTINE
+! A pure generic interface name is not a valid target of an OpenACC ROUTINE
 ! directive. The name argument denotes a subroutine or function; the same
 ! restriction appears in OpenMP for declare target procedure list items.
+!
+! Exception: when a generic shares its name with a specific procedure (a
+! common pattern with interface bodies), the name denotes that specific and
+! the directive is accepted.
 
 module m1
   interface foo
@@ -21,6 +25,18 @@ double precision function dbar(x)
   end function
 end module
 
+! Same-named specific inside the interface: routine attaches to the specific.
+module m2
+  interface generic_sub
+    subroutine generic_sub() bind(c)
+    end subroutine
+    subroutine other_sub(value) bind(c)
+      integer(8), value :: value
+    end subroutine
+  end interface
+  !$acc routine(generic_sub) seq bind("device_generic_sub")
+end module
+
 program gen
   use m1
   real :: y = 1.0, z

``````````

</details>


https://github.com/llvm/llvm-project/pull/211386


More information about the flang-commits mailing list