This is an archive of the discontinued LLVM Phabricator instance.

[flang] Avoid spurious error message in function result compatibility

Authored by klausler on Aug 18 2022, 11:23 AM.



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.

Diff Detail

Event Timeline

klausler created this revision.Aug 18 2022, 11:23 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 18 2022, 11:23 AM
Herald added a subscriber: jdoerfert. · View Herald Transcript
klausler requested review of this revision.Aug 18 2022, 11:23 AM
vdonaldson accepted this revision.Aug 18 2022, 11:44 AM
This revision is now accepted and ready to land.Aug 18 2022, 11:44 AM
jpenix-quic added inline comments.

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 as well--thanks!

klausler marked an inline comment as done.Aug 18 2022, 3:02 PM
klausler added inline comments.

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.

This revision was automatically updated to reflect the committed changes.
klausler marked an inline comment as done.
jpenix-quic added inline comments.Aug 19 2022, 9:33 AM

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 ( 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?

klausler marked an inline comment as done.Aug 19 2022, 10:39 AM
klausler added inline comments.

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?