[flang-commits] [flang] [flang][OpenMP]Add symbls omp_in, omp_out and omp_priv in DECLARE RED… (PR #129908)

[Mats Petersson via flang-commits]

================
@@ -1761,11 +1770,26 @@ void OmpVisitor::ProcessReductionSpecifier(
   // Creating a new scope in case the combiner expression (or clauses) use
   // reerved identifiers, like "omp_in". This is a temporary solution until
   // we deal with these in a more thorough way.
-  PushScope(Scope::Kind::OtherConstruct, nullptr);
-  Walk(std::get<parser::OmpTypeNameList>(spec.t));
-  Walk(std::get<std::optional<parser::OmpReductionCombiner>>(spec.t));
-  Walk(clauses);
-  PopScope();
+  auto &typeList = std::get<parser::OmpTypeNameList>(spec.t);
+  for (auto &t : typeList.v) {
+    PushScope(Scope::Kind::OtherConstruct, nullptr);
+    BeginDeclTypeSpec();
+    // We need to walk t.u because Walk(t) does it's own BeginDeclTypeSpec.
+    Walk(t.u);
+
+    auto *typeSpec = GetDeclTypeSpec();
+    assert(typeSpec && "We should have a type here");
+    const parser::CharBlock ompVarNames[] = {
+        {"omp_in", 6}, {"omp_out", 7}, {"omp_priv", 8}};
----------------
Leporacanthicus wrote:

We could add that code into the `OmpReductionInitializerProc`, where the code would be something like `initme(omp_priv)` - for the case of `omp_priv=7` or `omp_priv%x=1`, that is just a standard Fortran `AssignmentStmt`, which either would require an extra wrapper or additional code here to handle that case. Of course. 

I guess to avoid generating a symbol that isn'g used, we could check if there is an initializer (relatively easy in terms of code, as there is only one valid clause allowed here, so it's either an initializer clause or the clauselist is empty. It does add a bit more complication to this code, and I'm not sure it's worth the extra complexity to avoid generating the `omp_priv` symbol some of the time.

Is the concern here that these symbols will somehow cause a problem elsewhere? Or simply that we shouldn't do things that aren't required in general. They are in a local scope, so won't be visible outside of the declaration of the reduction.

[In theory, the `omp_in` may also not be used, but without following what's in the Reduction specifier, which could be an arbitrary expression as far as I understand, it's even harder to know if that is or isn't used].

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