[flang-commits] [flang] [Flang][OpenMP] Initial defaultmap(none) implementation (PR #166715)

[via flang-commits]

================
@@ -3000,6 +3066,36 @@ void OmpAttributeVisitor::Post(const parser::Name &name) {
       }
     }
 
+    // TODO: handle case where default and defaultmap are present on the same
+    // construct and conflict, defaultmap should supersede default if they
+    // conflict.
+    if (!GetContext().defaultMap.empty()) {
+      // Checked before implicit data sharing attributes as this rule ignores
+      // them and expects explicit predetermined/specified attributes to be in
+      // place for the types specified.
+      if (Symbol * found{currScope().FindSymbol(name.source)}) {
+        // If the variable has declare target applied to it (enter or link) it
+        // is exempt from defaultmap(none) restrictions
+        if (!symbol->GetUltimate().test(Symbol::Flag::OmpDeclareTarget)) {
+          auto &dMap = GetContext().defaultMap;
+          for (auto defaults : dMap) {
+            if (defaults.second ==
+                parser::OmpDefaultmapClause::ImplicitBehavior::None) {
+              if (DefaultMapCategoryMatchesSymbol(defaults.first, *found)) {
+                if (!IsObjectWithDSA(*symbol)) {
+                  context_.Say(name.source,
+                      "The DEFAULTMAP(NONE) clause requires that '%s' must be "
+                      "listed in a "
+                      "data-sharing attribute, data-mapping attribute, or is_device_ptr clause"_err_en_US,
+                      symbol->name());
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+
----------------
agozillon wrote:

Not too sure, I can try to do so on Monday when I look at updating the PR! The main reason it's here is that the equivalent check for default is above, and there is some interconnection between the two clauses if they appear on the same construct that I'll need to handle in a follow up PR. 

The only thing I can think of that might be a problem (aside from needing to supersede the default check above) is if check-omp-structure occurs after resolve-directives, as resolve-directives applies implicit DSAs to things almost immediately after this and from my understanding (from my admittedly shaky reading of the specification and testing with Clang at least) if you apply defaultmap(none), it'd require everything to be explicitly specified in a data sharing attribute or data mapping attribute (or use_device/has_device etc.). So the implicit application of the DSAs below would cause issues (and from last I checked they don't all get the implicit keyword applied at the moment as it impacts some other handling elsewhere, so it's likely not possible to check if all of the DSAs have appeared implicitly or if a user explicitly specified it). 

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