`fromJust` exception for subroutines without their definition in scope about fortran-src

[dorchard]

Actually, this is not the problem. I have reduced it down a bit more. The issue is (possibly reasonably) when calling subroutines that don't exist:

program fun
  implicit none
  integer :: x

  call someSUB(x)

end program fun

But I think we might want to accept this sometimes (a partial supergraph?) I guess this relates to our need to do multi-file analysis. I am getting this problem with some of the computational physics examples for CamFort.

[mrd]

Yep, it's functions or subroutine that don't exist.

A better error message is warranted, I suppose.

On Wed, Jun 1, 2016 at 10:58 AM, Dominic Orchard [email protected]
wrote:

Actually, this is not the problem. I have reduce it down a bit more. The
issue is (possible reasonably) when calling subroutines that don't exist:

program fun
implicit none
integer :: x

call someSUB(x)

end program fun

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAQmONZ5lbND5SOYz7lgV0CnQdvcCEcbks5qHVfPgaJpZM4IrYFZ
.

[dorchard]

It seems okay with functions, but I guess it's because they haven't been disambiguated from arrays?

[dorchard]

This bug strangely went away recently but now appears to be back (possibly with recent changes to the super graph building code)? We really need to be able to get round this.

[dorchard]

I can confirm that, if you don't build the supergraph this fromJust exception is not reached. In Camfort, in the stencil specs. inference part, if I just look at the graph associated to each program unit this goes away, but converting to the new supergraph raises this exception, so I suppose the problem is somewhere around the interaction of stitching and undefined functions/subroutines.

[mrd]

Well yeah. What do you mean the bug went away? Undefined functions are undefined functions. I can't do anything about the fact that they don't exist.

[dorchard]

Generating a flowsGraph for individual program units with undefined cals does not raise an error. Generating a flowsGraph from the supergraph of a program with undefined calls, raises fromJust somewhere. If a call is unknown, I propose we (for the moment) just let treat it as a no-op. I'm not sure where the difference in behaviour is coming out in the dataflow analysis, but I haven't stepped through the code carefully.

[mrd]

Right, because the supergraph must look up every function and subroutine call by its nature -- it's interprocedural analysis.

Doing only intraprocedural analysis does not require looking up other functions or subroutines.

[dorchard]

Ok. Can we just treat an unknown subroutine/function as a no-op for the moment? We can work to do cross-file interprocedural analysis later- but I think even if we can't find the definition in another file, for the sake of many of our analyses we want to just pass over it (we may want to control this per analysis).

[dorchard]

This has been dealt with and there is some better error reporting now in analysis code.