- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have some fortran source files which contains several functions and subroutines and I would like to get an overview of all function names and subroutine names which are included in the files e.g. a cross reference map or somewhat else. Unfortunatetly I cannot find compiler options that generate listings anyway.
Please can someone point me to a compiler option that generates some output listing.
thank you
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have some fortran source files which contains several functions and subroutines and I would like to get an overview of all function names and subroutine names which are included in the files e.g. a cross reference map or somewhat else. Unfortunatetly I cannot find compiler options that generate listings anyway.
Please can someone point me to a compiler option that generates some output listing.
thank you
AFAIK, IVF does not have such an option. I would be happy too if it were so.
When you only need a list of all functions and subrouties, take a lookat the debug directory. Every function and subroutine is compiled to a*.mod file for its own. With a simple dir command in a console you can store them into a .txt file (dir *.mod >> list.txt).
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, any movement here towards getting a simple call tree across multiple files and libraries?
The source list generation is only for single files, and is too detailed.
Thanks,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intel VTune Amplifier XE can create a call tree from runtime data. I'll comment, since the earlier replies in this thread are old, that we do now have a cross-reference listing, but as David says it is single file. We also have "Go to definition" and "Find all references" in Visual Studio.
We're not currently considering a static cross-file cross-reference listing capability.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
I want to be able to determine which of my hundreds of routines are still being used in my application, so that I can remove any obsolete files from my projects. My application has about 7 projects with many files.
Using VTune to use the runtime data, or the Code Coverage option only reports what is used for a particular run, not every routine that could be called. A static map would be useful. Any commercial packages to do this (plus lots more) cost up to $1000.
Is there any other way of getting this information?
Thanks.,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Even a traditional cross-reference map might not tell you about uncalled routines.
Try this. Build your program with /Qipo /Qopt-report-phase:ipo
You'll get output like this:
<C:\Projects\Lib4\source1.f90;-1:-1;IPO DEAD STATIC FUNCTION ELIMINATION;_SUB1;0 > DEAD STATIC FUNCTION ELIMINATION: (_SUB1) Routine was called explicity <C:\Projects\Lib4\source2.f90;-1:-1;IPO DEAD STATIC FUNCTION ELIMINATION;_SUB2;0 > DEAD STATIC FUNCTION ELIMINATION: (_SUB2) Routine was called explicity <C:\Projects\Lib4\source3.f90;-1:-1;IPO DEAD STATIC FUNCTION ELIMINATION;_SUB3;0 > DEAD STATIC FUNCTION ELIMINATION: (_SUB3) Routine is dead static
This tells you that SUB3 is never called (and even tells you which source file it came from.) In my test case none of the subroutines did anything, so you might not get the names of those that are called.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
David,
The IPO technique looks great. One caveat though. Should your code have conditional compilation options, you would need to ipo all the different conditional compilations, then excise the common dead code.
Conversely, you could remove all (conditional out), build all configurations, fix those that error'ed out, remove the remainder (but keep in a safe place). It is not unusual for a large project to contain a source file of a routine that had been "improved" and replaced. Only to then discover, perhaps years later, that the old routine was bug free, and the new routine had a hard to discover error. Having the old routine around for reference is always a good idea.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
Even a traditional cross-reference map might not tell you about uncalled routines.
Try this. Build your program with /Qipo /Qopt-report-phase:ipo
You'll get output like this:
DEAD STATIC FUNCTION ELIMINATION: (_SUB3) Routine is dead staticThis tells you that SUB3 is never called (and even tells you which source file it came from.) In my test case none of the subroutines did anything, so you might not get the names of those that are called.
I have tried this before and it does not work for me. I just added /Qipo /Qopt-report-phase:ipo to my project and did a clean build. Searching the output for the word 'DEAD' I get no hits even though I know there are some uncalled routines.
For example I know by doing a solution search that routine TORIVOL is never called but the only ref in the IPO report is:
UNREF VAR REMOVAL ROUTINE-SYMTAB (_AXS6_mp_TORIVOL):VARS(2),PACKS (2)
Does all the routines being in modules make some difference?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That report line does indicate a dead routine. So maybe there are other indications. It occurs to me that inlining might cause the compiler to remove the individual routine if it got inlined everywhere, so use the report as a list to work from rather than gospel.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are a large number of such messages, but most are used i think it is indicating inlining as you suggest but the TORIVOL routine exampled above is unreferenced so the report is not useful/not giving the information required.
I had some discussion of this on a thread a years or so ago but in the end I gave up with it.
Perhaps it depends on the optimisation option selected?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
While trying this, ifort gave me the following error ... any ideas:
ifort: error #10104: unable to open 'C:\Users\kwc54dw\AppData\Local\Temp\5824tempfile5'
Thanks,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Only references I got were like ...
<;-1:-1;IPO UNREFERENCED VAR REMOVING;;0>
UNREF VAR REMOVAL ROUTINE-SYMTAB (_MIX):VARS(25),PACKS (25)
These all seem to be due to variables rather than routines, since most, if not all of the routines are actually used.
I have function inlining turned off.
Thanks.
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mine are mostly used routines and I has warn on used variables are a standard setting so I do not tend to have any unused variables. Is the any help or reference to aid understanding on the IPO messages?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In compiler version 15 we've done a big overhaul of the optimization reports, and integrated them in Visual Studio so you can see notes interspersed with source.
Another idea I had for finding unused routines would have you put all the routine sources, except the main program, in a static library, link the main program to the library and generate a link map. This will tell you which object modules in the library were used - you'd then have to compare that to a list of everything to see which ones weren't used.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page