New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fortran main program call&caller graphs (Origin: bugzilla #523167) #2894

Closed
doxygen opened this Issue Jul 2, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

status RESOLVED severity major in component general for ---
Reported in version 1.5.5-SVN on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2008-03-18 13:43:38 +0000, Alin M Elena wrote:

in the case of fortran codes the main program does not get a call graph and is not included in any caller graphs

program test
implicit none

call a

end program test

subroutine a
print *, "Hello world"
end subroutine a

On 2008-05-26 11:11:26 +0000, Oleg Batrashev wrote:

I looked into this problem and it does not seem easy to solve. NamespaceDef entities are not MemberDef entities and it looks like many things has to be changes to solve this problem.

The easiest way (requires almost no changes) is to make Function entities from 'programs' and leave 'modules' as Namespace entities. I've tried it out and it works, the only visible consequence is that they are not listed under modules list anymore. Actually, it may be the correct behaviour, because they have code to run and their local variables are not exposed to others.

I do not know how and where global (not module) variables are declared. This may be important, because once we make Functions out of 'programs' we may get into troubles with their visibility.

On 2008-07-03 15:28:35 +0000, xavier perois wrote:

I found the same problem. The solution was to use a "C like" style with a main subroutine :

program test
call main()
contains
subroutine main()
implicit none
call a
end subroutine main
end program test

subroutine a
print *, "Hello world"
end subroutine a

Just a workaround with some lines more, but then you have a complete call graph

On 2009-06-20 21:26:54 +0000, AstroFloyd wrote:

Created attachment 137091
Proposed patch to treat PROGRAM statements in Fortran as subroutines and functions

This patch seems to fix the fact that the program statement in Fortran is treated by doxygen as a module rather than a subroutine or function. However, I don't know doxygen very well, so I may have missed something.

On 2009-06-20 21:30:17 +0000, AstroFloyd wrote:

(Apparently, I lost the body of my message while uploading the attachment in the previous post. Here it is.)

On 2009-06-20 21:31:05 +0000, AstroFloyd wrote:

(Apparently, I lost the body of my message while uploading the attachment in the previous post. Here it is.)

(In reply to comment # 1)

The easiest way (requires almost no changes) is to make Function entities from
'programs' and leave 'modules' as Namespace entities. I've tried it out and it
works, the only visible consequence is that they are not listed under modules
list anymore. Actually, it may be the correct behaviour, because they have code
to run and their local variables are not exposed to others.

I think this is the correct behaviour. The Fortran
program name
...
end program name

defines the main routine of a program, just like the

void main() {
...
}

statement in C. Hence there can only be one such routine in a program, and it
cannot be called by other routines. Other than that, the contents of a program
are the same as those of a subroutine or a function. Hence, a program should
NOT be listed under modules (as it is now) and should be treated as a subroutine
or function, so that it is included in the call graph (which it isn't at the
moment, which, it being the main routine, has quite an impact on the call graph.

I do not know how and where global (not module) variables are declared. This
may be important, because once we make Functions out of 'programs' we may get
into troubles with their visibility.

I have been programming in Fortran for about eight years now, and I have never
used a global variable (as they exist in C). I have tried to look up 'global
variables' in my reference books and google for them, but can't find anything
else than 'use modules' (or common blocks for Fortran 77).

It would be really useful if this change were made (treat program as subroutine).
I attach a patch for doxygen 1.5.8 that seems to do the trick, though I'm not
100% confident that I didn't miss anything. If someone who knows doxygen better
could check, that would be great, I'd like to push the patch into the Gentoo
package tree until it's resolved here.

On 2009-06-26 14:58:10 +0000, Oleg Batrashev wrote:

Created attachment 137423
Original (alternative) patch to treat PROGRAM statements in Fortran as subroutines and functions

This is one mentioned in comment 1. Need to figure out if this fix is better. In the while solving some serious caller/callee issues (local variables are ignored).

On 2009-07-18 21:56:19 +0000, Dimitri van Heesch wrote:

Thanks Oleg, I'll include your patch in the next subversion update.

On 2009-08-20 10:13:22 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.0. Please verify if this is indeed the case and reopen the
bug if you think it is not fixed (include any additional information that you
think can be relevant).

On 2015-06-16 17:25:23 +0000, Stas wrote:

For me this bug is still present in the version 1.8.9.

Can some one test it?

On 2015-06-17 15:55:44 +0000, AstroFloyd wrote:

Doxygen 1.8.9 seems to be fine for me. I just reran it for rochePlot and the program is recognised as such, and shows up in Caller and Callee graphs: http://tinyurl.com/oowsw99

On 2015-06-17 16:17:01 +0000, Alin M Elena wrote:

I tested it with my original example... and with the attached Doxyfle and works!

Regards,
Alin

On 2015-06-17 16:17:39 +0000, Alin M Elena wrote:

Created attachment 305493
doxyfile used

@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment