Multiple copies of same subroutine in single source file

[chauvjo]

I am working with a legacy Fortran program originally written on the IBM Mainframe. The single source file has several copies of the same subroutine. How can I determine which copy is used by the compiler?  Is this behavior the same for all compilers? What I really need is how the IBM Mainframe compiler handle this condition so I can identify and remove the duplicate subroutine that was ignored by the compiler used during the development of the code.

Thanks….

[DavidWhite]

You would not normally be able to compile such a file - Fortran requires all routine names to be unique, and so attempting to compile a file containing multiple copies of the same routine should fail.

There could, however, be conditional  compilation statements in the file, which means that code is excluded, depending on pre-defined values or compiler settings.

Are you able to post the code, for list members to review?

David

[chauvjo]

It is my understanding that on older compilers, you would get a warning but the code would still compile.  From what I been told, on the SGI, the compiler would issue a warning and use the first definition. The "first definition" was based on the compiler parsing the single source file starting from the top of the file and moving down.  It appears many programmers would store old versions of subroutines in the same single source file.

What I do not know is whether the old IBM mainframe Fortran from the 1980s use the first definition or used some other logic. Here is a simple example:

Program Main

CALL DupSub

STOP
END
Subroutine DupSub
WRITE(UNIT=0,FMT='(''First Definition'')')
RETURN
END
Subroutine DupSub
WRITE(UNIT=0,FMT='(''Second Definition'')')
RETURN
END

[IanH]

You'd be better off asking IBM.

[mecej4]

Typically, old compilers would compile each program unit within a source file and output the corresponding code and data sections into the object file, without attempting to cross check across subprogram boundaries. Thus, if the source file contained more than one instance of the same subprogram, there would be more than one instance of the entry point in the object code. Then, it would be up to the link-editor as to what to do with multiply-defined symbols. I do not see any justification for choosing any but the first instance of a code section. With common blocks, the story may be a bit different, but you are probably not interested.

A slightly different but still common scenario is one where the source file contains both single- and double-precision versions of the code (common with files from Netlib). You have to extract the desired version.

Do you really want to know what an old compiler did, and perpetuate the same dubious behavior?

[chauvjo]

IanH:  The IBM of the 1980s is long gone.  If you know of someone to contact, please let me know.  The only IBM Fortran forum I could find has not seen any activity since 2011

mecej4: Thanks for the reply. I am not trying to perpetuate this situation. Since I cannot determine by inspection which version of the duplicate subroutine the original developer wanted to use,  I assumed that best approach was to determine which version was used by the original compiler/linker and then removed the version which is ignored from the source code.  I can then compile the code using the Intel compiler without a duplicate definition error.

I think the SGI behavior of using the first definition is solid but some people who were around back then seem to recall the IBM Fortran using the LAST definition not the first.  So you can see my problem.  I am just trying to port a very old code to the PC and thought someone here might remember how the old IBM Mainframe VS Fortran Linker handled this situation.

[Steven_L_Intel1]

The compiler would probably compile all of them, leaving multiple definitions in the object. The question then is what does the linker do with multiple definitions, and this varies across platforms. The Microsoft linker, by default, considers multiple definitions to be an error. You can override this with a link option /force:multiple, but it will probably then take the first definition it sees.