When checking function interface compatibility for procedure pointer
assignment/initialization or actual/dummy procedure association, don't
emit a diagnositic about function result shape incompatibility unless
the interfaces differ in rank or have distinct constant extents on a
dimension. Function results whose dimensions are determined by dummy
arguments or host-associated variables are not necessarily incompatible.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
flang/lib/Evaluate/characteristics.cpp | ||
---|---|---|
878–893 | 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! |
flang/lib/Evaluate/characteristics.cpp | ||
---|---|---|
878–893 | 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. |
flang/lib/Evaluate/characteristics.cpp | ||
---|---|---|
878–893 | 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? |
flang/lib/Evaluate/characteristics.cpp | ||
---|---|---|
878–893 | Exact characteristic equivalence checking for dummy/actual procedure interfaces is necessarily inexact. Array bounds and length type parameters can be specified by means of arbitrary specification expressions, including calls to PURE user functions, whose values cannot be computed and checked at compilation time; neither is it possible in general to prove at compilation time that two specification expressions will or will not produce identical values at run time. A symbolic algebra system might be employed to do better than what's presently done, but in general this is not a tractable problem. And it's not one that a Fortran compiler is required by the standard to solve, since there isn't a numbered constraint here, just "shall" language in the normative text. So I've taken a conservative course that will *not* consider two procedure interfaces to be incompatible unless they blatantly are so in a way that might lead to incorrect code generation (e.g., 10 vs 20). In the example that you linked above, I think that gfortran's error could be inappropriate -- what if size(p) is always 10? |
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!