Slight disagreement with Premier support

[Greynolds__Alan]

I reported to Premier support the following "bug"which only occurswith IVF intel64 and not ia32(or on MacOSX)

c:\\ivf\\bugs>type test.f90
program test
external scale
call scale
end
subroutine scale
write(*,*) 'hello'
end

c:\\ivf\\bugs>ifort test.f90
Intel Visual Fortran Intel 64 Compiler Professional for applications ...
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
Microsoft Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
-out:test.exe
-subsystem:console
test.obj
LIBCMT.lib(_filter_util_.obj) : error LNK2005: SCALE already defined in test.obj
test.exe : fatal error LNK1169: one or more multiply defined symbols found

The problem is my "scale" routine name conflicts with a 64-bit Microsoft library symbol. Intel support says basically its not a problem with their compiler and I should just rename the routine (which I did as a workaround). I thought that "name-mangling" was supposed to avoid this EVER happening. Is this technically a violation of Fortran standards and it is something they should fix?

Al Greynolds
www.ruda-cardinal.com

[mecej4]

Why should the Fortran standard have anything to say about symbols in libraries? Can someone suggest a mangling scheme that guarantees that no symbol that you put in Fortran programs will ever clash with all the symbols in the thousands of DLLs that infest a Windows system? How can Intel use the force of the Fortran standard to tell Microsoft not to use certain symbols, when Microsoft can simply retort that none of their system code is written in Fortran and, therefore, the Fortran standard has no force?

You have some control over name mangling through compiler and linker options. You can also tell the linker to ignore all but the first-seen instance of any symbol (/FORCE:MULTIPLE). If you find yourself using some options frequently, you can put them in the configuration file for convenience. But don't, please, force those preferences on everyone. I, for one, would want to know about name clashes so that I can take appropriate steps to resolve them.

-----------------------
It is understandable that in developing a large project you are concerned with name clashes, and I found myself asking (after I wrote the two paragraphs above) why name clashes are so infrequent that when a clash does occur it is worth writing about.

I think that we can credit that infrequency to the ubiquitous use of shared libraries (.DLL on Win, OS2; .so in Unix/Linux; .exe on VMS). Of the many symbols in the source code used to build such a library, only a small fraction are "exported". The rest are all resolved and replaced by addresses when the shared library is built, and these symbols (the majority) are removed from possible future clashes with user symbols.

You could exploit this property of shared libraries. In particular, if all the routines that use SCALE and the routine that implements SCALE were put into a DLL, and SCALE was not exported, the name clash that prompted this thread would disappear.

[Greynolds__Alan]

Good points. But It brings up another interesting problem I have with Premier support. Many times I find that I appear I know more about Fortran than their first-line people (off-shore?). Why did they not make the same suggestions as you instead of telling me to alter my multi-platform multi-compiler standard Fortran source?

Al

[Martyn_C_Intel]

Hi Al,
Let me say a couple of words, (as a US-based first-line support engineer :-) ), in my colleague's defense.
Intel has customers spread worldwide, and therefore support staff spread worldwide as well.On the whole,support engineers tend to take issues submitted within or just before the workday of their own time zone, but there are plenty of exceptions.
In this case, the support engineer consulted a very experienced Fortran developer. As pointed out above, it's impossible to foresee the name conflicts that might arise between any arbitrary user symbol and a third party library. In this case, the symbol was introduced by Microsoft between one Visual Studio version and the next. (I would agree, that it seems like a symbol with a high risk of conflict). The suggestions of changing the subroutine name, or of redefining the symbol with a directive, seem likesensible, simpleones.
The internal run-time library symbols have names that make similar clashes unlikely. So the Fortran intrinsic SCALE does not cause a problem, for example. Putting an elaborate prefix on every user symbol doesn't seem very desirable. I think it's a reasonable question, why the trailing underscore that is used to distinguish Fortran symbols on IA-32 is not used by default on Intel64. (Al's issue does not arise on IA-32). If you wish, you can change this default with /assume:underscore, after which your program works.I don't know ifthis might cause other compatibility problems in a large program.
As you can imagine, changing sucha default at this point would break very many user programs, and would not be realistic.

[mecej4]

Al,

I added a couple of paragraphs to #1 with a suggestion for alleviating name clashes without your needing to resort to name decoration or renaming your routines.

[Martyn_C_Intel]

That's a good suggestion. In fact, it looks like Microsoft do not export SCALE, so just building with /MD makes Al's example work.

I'm told that it was Microsoft who changed the convention by removing the leading (not trailing) underscore for external references in Intel64 compared to IA-32. So Intel Fortran just copies that. /assume:underscore adds a trailing underscore, which is just one way of resolving the ambiguity.
Fortran symbols are by default converted to upper case, whereas C symbols are usually lower case or contain lower case (but a convention, not a rule). This helps avoid clashes.SCALE from MSVCRTis something of an exception in being upper case.