Skip to content

Conversation

@raehik
Copy link
Collaborator

@raehik raehik commented Feb 1, 2022

Analysis.BBlock.perBlock is where the decision is made on how to create blocks from call()s. Previously, it would check to see if the expression was assignable: either a plain variable, or a subscript. If so, it would "re-assign" them (I'm not completely clear on this part). Now, we treat bracketed plain variables as non-assignable, figuring that they're used as call-by-value.

Closes #203 .

TODO

  • perBlock: do same for the expression function call (pull the pattern out)
  • write some tests
  • document a bit clearer?

@raehik raehik changed the title func call var alias handling Handle call-by-value parameters Feb 2, 2022
@raehik raehik marked this pull request as ready for review February 2, 2022 13:55
@raehik
Copy link
Collaborator Author

raehik commented Feb 2, 2022

I believe we need to restrict the parameter re-assigning (-> call-by-reference) for more parameters: specifically, bracketed variables (a) do not get re-assigned (so they stay call-by-value).

I think my change works. The flows-from graph looks correct. @mrd , could I check in with you on this?

@raehik
Copy link
Collaborator Author

raehik commented Feb 2, 2022

I'm testing like so:

module m
    implicit none
    contains

    subroutine double(i, i2)
        integer, intent(in)  :: i
        integer, intent(out) :: i2
        print *, "entering double, i =", i
        i2 = 2*i
        print *, "leaving  double, i =", i
    end subroutine double

end module m

program overlapping_arg
    use m, only: double
    implicit none
    integer :: j
    j = 3
    call double(j, j)
    print *, "(1) in main, j =", j
    call double(j, j)
    print *, "(2) in main, j =", j
end program overlapping_arg

And running stack run -- test.f90 --show-flows-from=B13 --dot | dot -Tpng > graph.png. Bracketing various js in the 2 calls to double turns that usage to a call-by-value, which effectively removes that line on the data flow graph.

@raehik
Copy link
Collaborator Author

raehik commented Feb 3, 2022

I ignored the named parameter feature that Fortran has! Almost finished re-jigging the parsers to properly handle that. (I don't think we look at named parameters in the analysis, so I'm not fixing anything there.)

@raehik
Copy link
Collaborator Author

raehik commented Feb 14, 2022

Pending while we resolve some potential issues with the --show-flows-{to,from} flags -- they give unexpected output, which could be flipped directions or just ambiguous naming

@raehik raehik added the raehik-wrapup-2023 For @raehik to tidy up by their formal 2023 post end date. label May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

raehik-wrapup-2023 For @raehik to tidy up by their formal 2023 post end date.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Copying prior to pass-by-reference triggered by parentheses, which we ignore.

2 participants