Cross reference (XRF) file

This is a bit long, so bear with me. Bottom line here is a question whether there is an issue with the XRF file that can be fixed/should be fixed, or if this is what you get (which, errors or not, can be very useful).

I was using the XRF file produced by the compiler, and it occurred to be that I could process the file into a different form. Rather than the report which is 'Module/Function/Routine uses: xxxxxx' I could gather all the XRF files together and produce a 'Where xxxxxx is Used' report/file. I find that more useful if I am making a change at a lower level and need to make sure I haven't forgotten something about the using program

I took one of my larger routines and looked at what the report contained. I noticed certain defining features. So I coded a 'scanner' to look for those features. Reviewing the output, I discovered certain features that I had seen/vetted in the original file were not presented the same way in other files. So, I thought I'd ask the question: What should I be seeing?

While the line numbers assigned are some sort of internal number (don't match 'actual' numbers), they are not always present. Specifically, the entry for 'SUBROUTINE XXXXX' should show a line number where it was used. This is inconsistent.

Similarly, with functions. An interesting side note is that a function declared as EXTERNAL in an include file will show a tilde by the line number, what is sometimes missing is the list of line number where the function is actually used. So, having an INCLUDE that defines a BUNCH of EXTERNAL routines will have a really big list of routines most of which are not referenced in the routine that will only show they were defined, but several of them will also show that they were used (a line number by itself) when they were not.

I have lots of XRF files that have one or all (there are a couple more things) of these discrepancies, and can provide them for review if that would be helpful.

And, I may be the only one trying to use this, particularly in this way. In which case, I can try something else.

Bill, I have used both the /xref and /exp listings for specific purposes in the past, writing filters to process the *.LIS and *.XRF files so generated.

There are more limitations to these listings than those that you have noticed. For instance, it reports a variable CMULT in a module ELEM20NODE as

DOUBLE PRECISION, {Offset 0 in Common/@@ELEM20NODE!CMULT/} , DIMENSION(73968) -- there are no common blocks anywhere in any of the source files, so this is probably some form of internal/intermediate representation. Similarly, it reports Generating information for SUBROUTINE ELEM20NODE (from module ELEM20NODE) when there is no such subroutine, and reports PROGRAM TST as SUBROUTINE TST.

If you want more accurate cross-reference and similar listings, you probably have to look elsewhere or roll your own.

As you have guessed, the number of users who still use such listings, and the number of compilers that still generate such listings, are both small and dwindling.

Yes, it is (to some) an arcane way to look at your software. But, it works for me.

And, as I age, I find I need a few more tools other than just my memory to remember where each variable is used in COMMON, or where various blocks of code are used and need extra care when updating!

Also, in leaving a trail of breadcrumbs for someone who may follow my passing, I am doing them a favor. Not that this is imminent......

Bill,

Paul is investigating changes to /xref and has provided me with a new option /XREF1 to FTN95 as an initial response to my enquiry.

My enquiry in April 2019 related to:

• errors in the .xrf listing where extra lines were reported, and
• the possibility of having the .xrf file in a .csv format to assist with analysis in Excel.

see https://forums.silverfrost.com/Forum/Topic/3536

The new option: /XREF1 provides a simplified xref file that lists only the routines that are defined in the file together with the routines that each one calls.

This could be used to assist in generating a routine cross reference, which I will try to analyse in a pivot table or similar, else in a Fortran program.

I provide this comment, as if /xref is being revised, perhaps we could provide Paul with a targeted description of what should be in the /xref1 report, how it could be presented and cover what we could then analyse.

I use the term 'targeted' as I am not suggesting that this explodes into many different requests that would make it impossible to complete.

My original request was to: First duplicate a report something like (what I recall as) '/xrefs' in Pr1mos Fortran, which listed only routines or variables that were referenced in the routine. Hence variables in common (or modules) that were not reverenced in the code would not be listed (or have no line numbers) Next I would like the report to have a structure, which could be read as a .csv file (like /timing) to be analysed (by my program or excel) to produce a cross reference for routines or common/module variables.

Does this align with your post ?

John, thanks for the additional information, and glad to know I'm not the only one who can use tools like this!

/XREF1 lists all routines, meaning routines I have in an INCLUDE file (to use as callbacks, for example), but don't actually reference in the current program module, are included in that listing. For me, no joy. That said, it is a nice, concise listing, and much easier to scan visually.

I do like your list of desires, though.

Routines actually used would be most helpful to me. The reference to the declaration can be helpful, but would not be required (i.e. where an EXTERNAL type is declared).

Also, like the current listing, the NAME (and kind) of routine is helpful. Currently, SUBROUTINE, INTEGER, CHARACTER, etc. functions are all identified as such. Couple this with the /DUMP list and you could actually reconstruct the arguments list and include that in a cross-reference listing.

CSV format would be fine with me. I would wish to know the contents of the data line to make sure I can use the information.

For example, I can deal with the current XRF file just fine, so long as the line numbering/tagging is consistent (which it is not). Meaning that the definition of the routine being used (if present) is indicated in the listing, and if it is actually used, that this is also indicated in the listing. For me, knowing precisely where it is used, or how many times is irrelevant; it is important that I know which routines/functions are used so I can construct the appropriate where-used list.

I think I've answered your questions, but if not, let me know! Bill

As a fellow addict, I offer to share with you a small utility that I built by adapting Bill Silvert's old FXREF utility for generating a cross-reference listing for Fortran 77 programs (that old version is still available at http://www.ugu.com/sui/ugu/show?I=software.progutil&F=1111111111&G=Y or from me). For the test program of my previous post https://forums.silverfrost.com/Forum/Topic/3439 , which is too long to post but is available for download from Dropbox ( https://www.dropbox.com/s/mr5yyuzihwvwj2n/xlmp11.zip?dl=0 ), my utilty generates the following listing:

Module      refnum_C                   3 -     5
            call elapse_time(t0)                        33
            call initpt (n, x, factor)                  36
            call ssqfcn (m, n, x, fvec)                 37
            call lmder1 (fcn, m, n, x, fvec, fjac, l    40
            call ssqfcn (m, n, x, fvec)                 42
            call elapse_time (t1)                       51
Program     main                       7 -    65
            call ssqfcn (m, n, x, fvec)                 80
            call ssqjac (m, n, x, fjac, ldfjac)         83
Subroutine  fcn                       67 -    87
Subroutine  ssqjac                    89 -   121
Subroutine  initpt                   123 -   133
Subroutine  ssqfcn                   135 -   164
            call lmder (fcn, m, n, x, fvec, fjac, ld   194
Subroutine  lmder1                   165 -   200
            call fcn (m, n, x, fvec, fjac, ldfjac, i   253
            call fcn (m, n, x, fvec, fjac, ldfjac, i   261
            call fcn (m, n, x, fvec, fjac, &           266
            call qrfac (m, n, fjac, ldfjac, .TRUE.,    270
            call lmpar (n, fjac, ldfjac, ipvt, diag,   325
            call fcn (m, n, wa2, wa4, fjac, ldfjac,    333
            call fcn (m, n, x, fvec, &                 396
Subroutine  lmder                    201 -   399
Function    dpmpar                   400 -   414
            call qrsolv (n, r, ldr, ipvt, wa1, qtb,    515
Subroutine  lmpar                    415 -   545
Subroutine  qrfac                    546 -   641
Subroutine  qrsolv                   642 -   733
Function    enorm                    734 -   787
            call system_clock ( clock, rate )          792
Subroutine  elapse_time              789 -   794

Please note that the utility is stand-alone, and not tied to the FTN95 compiler in any way.

Awesome, and thanks! I've downloaded it and will take a look.

Bill

Please note that I have not yet made available my utility program for listing subprograms and calls. Since you are interested, I'll collect the pieces and post a zip file in a few hours.

The heart of the utility is a Lex/Flex script, which specifies what patterns the scanner is to search for. Running Flex on the Flex script generates a C program. I have modified the Flex script such that the output C code can be built using Visual C++. I'll provide in the zip file the Flex script, the generated C source files, and a pre-built EXE.

I suggest that you use only the EXE on your Fortran sources, for a while. You can then provide me your feedback on the program's shortcomings, and I can update the program later if feasible. For this limited usage, you will only need the Visual C runtime, which is probably already on your PC, as a prerequisite.

P.S.

Here is the download link for showFsubs:

 https://www.dropbox.com/s/shstlv21scjd79g/showFsubs.7z?dl=0

If you modify the Lex script, showFsubs.l, and have GNU Flex and Visual C++, here are the commands to use to recreate the EXE:

flex -i -t --yylineno showfsubs.l > showfsubs.c
cl /O2 /MD /DYY_NO_UNISTD_H /I. showfsubs.c yywrap.c wingetopt.c

Thanks for the offer. I am not in a hurry, so no worries there.

Bill

It's ready for you to try out. Use the Dropbox link in the post preceding your last one, unzip and run your AV program on the EXE before trying it on a source file.

I downloaded the sources, and was pleasantly surprised by the YACC and LEX references in the file. An elegant solution, for sure. I'll give it a workout!

Bill