Odd warning messages from linker/compiler?

[abrsvc]

In the course of "porting" an application from the Alpha to the Itanium platform, I ran into an odd error message:

The scenerio:

HP zx6000 (1.50GHz/6.0MB) running OpenVMS V8.4

HP Fortran V8.2-104939

The source FORTRAN file contained many modules 1 of which has a warning about a variable being used before it is defined (I'll fix that later as it is in a module that is not currently used.)  The linker reports compiler warnings for 5 modules rather than 1.  It seems, that once a compiler warning is encountered, any module "linked" after that is also flagged as having warnings even when they do not.  There are 4 subroutines/functions in the suource file after the one with the error.

Since this application is a home grown one (my use only), I am using the hobbyist license and thus do not have a way to officially report this.  Can someone that has a contract forward this along?  This is new to Itanium as this is not a problem on the Alpha.

Thanks,

Dan

[Tom Wetty]

Warning messages in the Linker are more important than you realize.  Because of the library and the options etc you can use in the linking statement errors will cascade... for example

%ILINK-W-NUDFSYMS, 1 undefined symbol:

%ILINK-W-USEUNDEF, undefined symbol SCSLOGERR referenced

section: $CODE$

offset: %X0000000000002C90 slot: 0

module: PURGE_CYC$MAIN

file: SAPDEV$DKB1:[WMS.VWRTOM.SOURCE.SCS]SCSLIB_AXP.OLB;1

$ !

$ LINK/NOMAP/EXE=WMS$$EXE_SCS:PURGE_QUE SCSLIB_AXP/INCLUDE=PURGE_QUE$MAIN,-

WMS$$SRC_SCS:SCSLIB_AXP/LIB, -

WMS$$SRC_BLD:WMSLNKNFD_AXP/OPTION

WMS$$SRC_COM:COMLIB_AXP/LIB,WMS$$SRC_SRS:SRSLIB_AXP/LIB, -

WMS$$SRC_FPC:FPCLIB_AXP/LIB, -

WCH_VWRTOM> help/message NUDFSYMS

　

NUDFSYMS, 'number' undefined symbols:

Facility: LINK, Linker Utility

Explanation: The linker found undefined symbols at the end of Pass 1.

User Action: Ensure that all referenced symbols are defined.

　

NUDFSYMS, 'number' undefined symbols:

Facility: ILINK, OpenVMS I64 Linker Utility

Explanation: The number reported is the number of references found that

remain unresolved.

User Action: None.

Make sure your object files are compiled cleanly and in the libraries they are being linked from to clear the problem.

[abrsvc]

A compiler warning in one module should not affect the following modules during a link which is the complaint here. Please note that the compiler warning is caused by a lack of initialization of a variable and is only a warning. While this is esentially easy to fix, the reported issue here is the warnings issued by the linker for modules that do NOT have compiler warnings. In the group of 100+ subroutines/functions, only 1 has a warning, yet the linker reports that there are 5. The pattern is that the linker will report compiler warnings for ALL routines AFTER the one that actually has the warning. If hte module is the last in the source file, the linker will report that module as having the problem.

Please realize that this can be avoided by fixing the offending module. I get that. The problem I am trying to report is the LINKER reporting warnings where there are none (in the subsequent modules).

Dan

[H.Becker]

The OP talks about compiler warnings, which the linker reports (and incorporates into images).

That was always the case on Alpha and Itanium.

>>> The linker reports compiler warnings for 5 modules rather than 1.  It seems, that once a compiler warning is encountered, any module "linked" after that is also flagged as having warnings even when they do not.  There are 4 subroutines/functions in the suource file after the one with the error.

The linker should flag only the module/shareable image with the warning, nothing else. That's the case on Alpha. Can you show some real output, or the linker map? /full/cross would be nice, if it isn't too big. And if you are at it, a analyze/obj of a module with the warning and and a subsequent one without.

From your text, it isn't obvious to me what you mean with the sentence "There are 4 ..." (or do you want to say that you use a plus list to have multiple modules in one object file?).

[Tom Wetty]

just trying to help without a log attachment your explanation is a bit ambigous.

[abrsvc]

There is one FROTRAN source file that containes over 100 subroutines and functions which produces 1 object file. This .obj file is inserted into a .OLB with a nother .obj from a MACRO32 compilation. This .OLB is then "linked" into a shareable image using an options file with a list of the procedures. The linker only reports compilation warnings from the FORTRAN .OBJ file and for the last 5 subroutines/functions in the original source file. Note the subroutine that has the warning is in position "A" as shown below:

$link x/share=y sys$input/opt
symbol_vector=(x=procedure,-
y=procedure,-
z=procedure,-
A=procedure,-
b=procedure,-
c=procedure,-
d=procedure,-
e=procedure)

=====================
I will work on a small reproducer as I am restricted on the distribution of hte actual code.

Dan

[H.Becker]

The compiler warning belongs to the end of module information. On Alpha this is in the EEOM record, on Itanium it is in the ELF header. So the linker should report the warning per module, not per function/subroutine.

On Itanium you may want to do an $ pipe analyze/obj/header of_the_object_file |search sys$pipe "Completion Code:",flags. It is quite posible, but I can't check from here, that the FORTRAN compiler generates multiple object modules and puts them into one object file. The above command would then show more than two output lines. (How many elements, that is object modules are in the OLB?)

[abrsvc]

SOrry about the delay in updates. For some reason, my update did not make it and I was unable to access again...

Anyway, using the PIPE as described before indicates that the singular .OBJ file contains multiple object modules. I got over 100 lines from the command.
I also noticed that the Librarian displayed the same issue. So this in fact may be a problem with the object module creation not the linker or librarian. I noticed that the "warning" flag was set in all of the modules after the one thta actually had the warning.

At this point, I would think that this should be escalated to the compiler group. I will test this with another language sometime to see if this is a common issue.

Thanks for the assistance,
Dan

[H.Becker]

>>> At this point, I would think that this should be escalated to the compiler group. I will test this with another language sometime to see if this is a common issue.

For a number of reasons, I didn't really expect that the linker had a problem. Also, I don't know which other compilers besides BLISS can create multiple object modules from a single source file. For BLISS however you have to explicitly specify different modules in the source. Then BLISS generated object modules show the same problem. So it looks like a "common issue". (For almost all compilers, you can compile many sources into one object module, but that is quite the opposite of what FORTRAN is doing here.)

You probably fixed the problem in the source code, which caused the  warning. If applicable, the other options are to split the source after function A or to move function A to the end of the single source.

[John Reagan]

Fortran generates multiple modules per object file (ie, each subroutine turns into a separate module).  BLISS can do it, but that isn't the normal coding style.  I think you can get COBOL to do it also.