[flang-commits] [flang] [flang][Semantics][OpenMP] Check type of reduction variables (PR #94596)

[Tom Eccles via flang-commits]

================
@@ -2378,6 +2378,89 @@ bool OmpStructureChecker::CheckIntrinsicOperator(
   return false;
 }
 
+static bool isReductionAllowedForType(
+    const parser::OmpClause::Reduction &x, const DeclTypeSpec *type) {
+  assert(type && "no type for reduction symbol");
+  const auto &definedOp{std::get<parser::OmpReductionOperator>(x.v.t)};
+  // TODO: user defined reduction operators. Just allow everything for now.
+  bool ok{true};
+
+  auto isLogical = [](const DeclTypeSpec *type) -> bool {
+    return type->category() == DeclTypeSpec::Logical;
+  };
+  auto isCharacter = [](const DeclTypeSpec *type) -> bool {
+    return type->category() == DeclTypeSpec::Character;
+  };
+
+  common::visit(
----------------
tblah wrote:

Thanks for the suggestion. The two functions are similar but not identical:
- No complex numbers in CUDA
- No subtract in CUDA (although perhaps we don't need to handle that here for OpenMP because it is currently a compiler error to use subtract anyway).
- OpenMP describes iand,ior,ieor,min, and max differently. The OpenMP 5.2 standard (5.5.1) does distinguish between operators and intrinsic procedure names, however I don't think there are any substantive differences between how these are treated.

@kiranchandramohan what do you think - would it be a good fit to change the representation to use `parser::ReductionOperator` instead of `parser::IntrinsicOperator` for these built in reduction operations, so that we can then refactor to share with the CUDA code? I think as a side effect this could let us use the existing array reduction machinery for `min` and `max` without additional work (other than tests).

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