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

[Kiran Chandramohan 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}};
----------------
kiranchandramohan wrote:

Are you taking advantage of the fact that the only variables that are permitted in the Combiner and Initializer are omp_in, omp_out and omp_priv?  Hence there is no need to traverse to these names because we already know them?

The points I am not following are:
1. If we create symbols like these do these symbols get attached to the parser::Name in the Assignment Statement?
2. What happens when there are multiple types in the typelist? Since only the type has changed, do the ones created in the latter trips of the loop override the ones created previously.
3. omp_orig can also appear in the initializer.

Since there is a loop here, we should have at least a test with more than one type.

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