cross version MOD file compatibility

[Daniel_P_4]

Our F90 based product ships w distributable LIB and MOD files which are compiled into a binary executable each time the user runs the product. I've been working in v10.1 for a long time. I recently discovered I have problem delivering IFORT10-compiled MOD files to IFORT11 (and higher) users in IA32. Problem seems to be caused by symbol names generated by compiling modules. It appears standard to put the underscore in front of symbol names. For subroutines & functions, that is what I see across 4 different IA32 IFORT versions (9 thru 12). However, in version 9 & 10, it seems there is no underscore for symbols generated from modules, and starting in v11, the underscore prefix is present. This renders my IFORT10-compiled MOD and (and possibly LIB) files unusable under IA32 IFORT 11 & 12. If there is a cleverly used compiler option, compiler directive (!DEC$ for example), link option (using v8), or code trick - I sure would appreciate it. If what I want is simply impossible, it won't make me happy, but at least I can stop trying to climb this particular tree and move on.

Our code runs in 2 different IA32 forms plus EM64T form, which means I have to deliver a minimum of 3 sets of MOD/LIB files. I'm trying to avoid delivering version-specific files tha span v9 thru v12 - that would be 12 sets of files - unwield for my limited resources.

NOTE - I do not seem to have this problem in the em64t version, though I do seems to have some kind of symbol naming problem when I try to build the em64t MOD/LIB files with v9.1 IFORT (I'd like to know what to do about this too, if possible - just in case I have to build version-specific MOD and LIB for every situation).

THANKS in advance for any advice or ideas

[mecej4]

I cannot check all the compiler versions that you mentioned, but here is something that is not clear: are you trying to use .MOD files across targets? In other words, are you creating .MOD files with a 32-bit compiler and then trying to use them in a 64-bit build? That will not work, one reason being that external name decoration is different for 32-bit and 64-bit objects.

I have noticed occasional .MOD file incompatibilities between Ifort 11.1 and 12.0. A solution in this case, one which is used, for example in the IMSL library, is to provide the source code for a module containing just the interface blocks to the routines in the library.

Does your library export module procedures or only external procedures?

[Steven_L_Intel1]

We try very hard to make .mod files upward compatible - that is, usable in newer compiler versions. However, sometimes there are bugs that make the modules incompatible and you hit one of them, where we were improperly "decorating" module variables in some cases. The compiler release notes list issues in a "Compatibility" section.

I am a bit puzzled by your description of the problem, though, as I am aware of a decoration issue only on the Intel 64 platform. Can you provide a short example that shows the problem? I may be able to offer some tips.

[Daniel_P_4]

mecej4:

I'm sure I'm not cross 32 and 64 bit versions. The modules in question came from refactoring old code that used static allocation and common blocks, replacing it with modules and dynamically allocated "c pointer" arrays. The modules in question do nothing more than declare the things that were once in common blocks - one module per replaced common block. These modules CONTAIN no functions or subroutines. The link error I'm having happens when I try to access a variable or array declared in one of these modules.

[Daniel_P_4]

Quoting Steve Lionel (Intel)

We try very hard to make .mod files upward compatible - that is, usable in newer compiler versions. However, sometimes there are bugs that make the modules incompatible and you hit one of them, where we were improperly "decorating" module variables in some cases. The compiler release notes list issues in a "Compatibility" section.

I am a bit puzzled by your description of the problem, though, as I am aware of a decoration issue only on the Intel 64 platform. Can you provide a short example that shows the problem? I may be able to offer some tips.

Steve

I was aware of the 64bit decoration issue too. I might yet crash my face into that one too, though if I set up with version-specific deliverables, I should be OK - it's just a lot lot more complex to collate all the parts from the other contributors - suddenly having to ask them for 4 builds instead of just 1, or taking over the builds myself and incorporating it into my tooling and scripts.

It seems that in v10.1 and earlier IFORT did not decorate some symbol names coming from a module. My modules are pretty much declaration-only, no procedures. For example, I can see FIXCON_mp_CCONSTANTS as a symbol when compiled with v10, but compiling with v11 I see _FIXCON_mp_CCONSTANTS instead.

It seems v10 names these symbols in the 64bit fashion, inconsistently decorated relative to all the other ia32 named symbols, and that y'all fixed it in v11 - consistent symbol decorations regardless of where the symbol comes from.

Is there a way to override ro control this decoration in F90 that will work across the v9 thru v12 range?

Below is an email I wrote to a coworker, and the referenced files are attached.

It sounds like I should plan on version-specific deliverable, eh?

Dan

======================

Please see attached mini project

MAIN = main program

FIXCON = results in both MOD and OBJ files

OBJECT = subroutine that is called by MAIN and uses FIXCON

Note the txt files I think the names explain what is in each the dumpbin /symbols for FIXCON and OBJECT

At a glance, I see no name mangling in the 64bit stuff. However, I do see a reference to a symbol named __ImageBase (double underscore). This is present in FIXCON.OBJ from IFORT11 but not present in IFORT10.

For the 32bit version, I see name mangling. IFORT10 fails to put the underscore in front of the FIXCON symbol and IFORT11 does put it there. I cant seem to find any compiler or code generation options that manipulate this underscore prefix. Underscore suffixes that I can find, but not prefixes.

Please look over the TXT files with your more trained and in tune eye and let me know what you think.

Im still hoping to find some kind of code generation option that will make it work.

In general, I hope to find

As it stands right now, to get it working with IFORT11, I have to do 2 things

1. 64bit: Re-do the MOD files with IFORT11

2. 32bit: Re-do both MOD files and LIB file with IFORT11

Doing this results in a IFORT11-only build with no backward compatibility.

Its looking more and more like Im going to have to build compiler-version specific MOD and TLIB files. Thats going to impact the installer a lot more than wed like, Im afraid.

Dan

=====================

[mecej4]

I happened to have IFort 8.1/IA32 on an old computer, and I think that I see the problem. Variables in modules, such as CCONSTANTS in the example supplied, become FIXCON_mp_CCONSTANTS in IFort 8.1/IA32, but _FIXCON_mp_CCONSTANTS in IFort 11.1/IA32 and 12.0/IA32 (a leading underscore is added, as for external subroutine and function names). Any other source files which USE the module with the variables also will result in OBJ files with the same decorated variable names, causing an incompatibility between objects and libraries built with versions before 11 and other objects and libraries built with newer versions of the compiler.

I do not know if a similar problem exists with respect to module procedures, since the example does not contain any. This needs to be checked.

Because of the symbols being present in the .OBJ, .LIB and .DLL files, making the source of the constants module available, as I thought earlier might be sufficient, is not a solution.

I have verified that modules and objects produced by 11.1/IA32 and 12.0/IA32 are forward and backward compatible. Therefore, one solution would be to exclude the use of compilers earlier than 11.1 (possibly 11.0, I have not got that version).

[Daniel_P_4]

Mecej4

Yes, that is the problem -

Eliminating v9 might be an option, but I can't eliminate v10. I might come up with a single file set for v9/10 and another for v11/12 though.

I'm hoping (not expecting) Steve will come up with a nugget of wisdom or technique that might help me a bit.

Thanks for yor interest and help!

Dan

[Steven_L_Intel1]

Ah - it's the EQUIVALENCE that is the key. We definitely had a bug in this area where the compiler inconsistently applied the leading underscore, sometimes it did, sometimes it didn't, when building the module. That was indeed fixed in 11.1, though a subset of the issue was fixed in 11.0.

I cannot think of a good workaround, unfortunately. If you can eliminate the use of EQUIVALENCE with module variables that would be best, but I recognize that is a major effort.

[mecej4]

In the example provided, the array variables CConstants and IConstants appear only in the module fixcon and their elements are equivalenced to other variables that are used in the other source files. It appears that these two arrays may have served only to preserve sequence position in the common blocks that were converted to modules, and may be removed. That leaves two more pairs of equivalenced variables. Again, only one member of each pair is used elsewhere, so the other member of each pair may be removed. With these changes, it is possible to compile some sources with IFort 8.1 and some with 12.0 (both 32-bit) and link the objects together.

Whether Dan can do something similar to this with his real project is debatable, unless the equivalence declarations in it are equally dispensable. The facility for renaming USE associated variables may be used in place of equivalence in those source files where different names are desired.

[Daniel_P_4]

Thanks - I don't think I can dispense with the EQUIVALENCE statements very easily, at least not with my remaining schedule.

I'm trying to keep code alive that's been in use for more than 30 years without ever knuckling down for that proper rewrite that perpetually gets put off. The way this stuff was written was elegant for its time, but you just wouldn't do things that way now days.

Thanks to you both for the help and guidance,

Dan