[flang-commits] [PATCH] D132162: [flang] Avoid spurious error message in function result compatibility

[Jonathon Penix via Phabricator via flang-commits]

jpenix-quic added inline comments.


================
Comment at: flang/lib/Evaluate/characteristics.cpp:878-893
+static bool AreCompatibleFunctionResultShapes(const Shape &x, const Shape &y) {
+  int rank{GetRank(x)};
+  if (GetRank(y) != rank) {
+    return false;
+  }
+  for (int j{0}; j < rank; ++j) {
+    if (auto xDim{ToInt64(x[j])}) {
----------------
klausler wrote:
> jpenix-quic wrote:
> > Does this differ from what ShapesAreCompatible does (characteristics.cpp:41-57)? They seem like they are doing the same thing, but I might be misunderstanding something (and apologies in advance if so!).
> > 
> > Either way, FWIW I think this should fix https://github.com/llvm/llvm-project/issues/57204 as well--thanks!
> ShapesAreCompatible() will return false when one corresponding dimensions is deferred but the other is not.  AreCompatibleFunctionResultShapes will return false if corresponding dimensions have distinct explicit extents.
Ahh, I see--thank you for clarifying for me! 

Just to double check though, is the ShapesAreCompatible() behavior desirable here? For example, with this code (https://godbolt.org/z/x7srK54b7) where there is a mismatch between the interface and passed function having assumed or explicit extents, respectively, gfortran and ifort are both rejecting this code while flang using AreCompatibleFunctionResultShapes() accepts it. I tried looking through the standard to see what is correct, but I don't understand well enough to know for sure--is the bit about non-constant bounds in function result arrays in 15.3.3 relevant here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132162/new/

https://reviews.llvm.org/D132162