Global symbol too long warnings with 12.0.0.0.0.0.104

[IanH]

I'll admit at times I'm a little verbose with my symbol names - I figure I have to make up for all those years where six characters was the maximum. But 12.0 is giving me warnings such as:

[plain]H:\Visual Studio 2005\Projects\SecretPlans\SecretPlansForTakingOverTheWorld.f90(1): 
  warning #5462: Global name too long, shortened from: 
  _S_CRETPLANSFORTAKINGOVERTHEWORLD$SECRETPLANSFORTAKINGOVERTHEWORLD_mp_DEVELOP_WINDOWS7$BLK..T7492_ 
  to: _CRETPLANSFORTAKINGOVERTHEWORLD$SECRETPLANSFORTAKINGOVERTHEWORLD_mp_DEVELOP_WINDOWS7$BLK..T7492_
! $Id: SecretPlansForTakingOverTheWorld.f90 1083 2010-10-01 07:56:07Z billg $
^
[/plain]

where the procedure in question is a private module procedure. From looking at the assembly, 11.1 just used the symbol SECRETPLANSFORTAKINGOVERTHEWORLD_mp_DEVELOP_WINDOWS7$BLK..T7492_

Few questions:

- Is it safe to ignore this?

- What's the reason for the symbol mangling change?

The symbol seems to have something to do with the specification part of the procedure, but I've not been able to make a small reproducer to understand further.

Thanks,

IanH

[Steven_L_Intel1]

The object language has a limit on the size of a global name. The compiler constructs global names combining the module and symbol name, and sometimes additional context necessary to disambiguate it. If the combined length exceeds the maximum, it gets shortened. We had several issues with the old way of doing it - one was that we were not sufficiently qualifying names within module or contained procedures. A second was that the name we did use could have been constructed by the user. The first change lengthens the constructed name, and the second one adds the dots.

[lklawrie]

No ICEs here but repeated module names:

D:\EPPgm\DBL_Source\ElectricPowerGenerators.f90(1): warning #5462: Global name too long, shortened from: _GE_ERATORDYNAMICSMANAGER$generatordynamicsmanager_mp_setupgeneratorcontrolstatemanager$BLK..T1609_ to: _ERATORDYNAMICSMANAGER$generatordynamicsmanager_mp_setupgeneratorcontrolstatemanager$BLK..T1609_

At least I think what you're calling repeated. mine aren't in UPPERCASE -- I think i have the switch on to put externals in lower case (due to some mixed language stuff)

Linda

[Steven_L_Intel1]

I'd really like to see a source file that does this...

[lklawrie]

Quoting Steve Lionel (Intel)

I'd really like to see a source file that does this...

I hope this is enough to illustrate. I tried to comment out a lot of usual stuff but still keep enough to maybe compile (I did not try to compile and obviously a lot is missing)

Linda

[Steven_L_Intel1]

Linda,

Thanks, but too much is missing from this. Can you attach just the ElectricPowerGenerators.obj file? It might give me a clue.

[lklawrie]

Two files attached the ElectricPowerGenerators object file and the .mod file from the one that says it is too long.

If I have some time, I will gen up a full project that uses this.

Linda

[lklawrie]

Here's a full zip of the files and a small main program wrapper. A gazillion warnings and, unfortunately, does not generate this warning that we're seeing in our real project. But maybe it will help.

This is just the debug configuration.

[lklawrie]

In addition to the little project. Here are the two messages generated:

D:\EPPgm\DBL_Source\ElectricPowerGenerators.f90(1): warning #5462: Global name too long, shortened from: _GE_ERATORDYNAMICSMANAGER$generatordynamicsmanager_mp_setupgeneratorcontrolstatemanager$BLK..T1609_ to: _ERATORDYNAMICSMANAGER$generatordynamicsmanager_mp_setupgeneratorcontrolstatemanager$BLK..T1609_

^

D:\EPPgm\DBL_Source\ElectricPowerGenerators.f90(1): warning #5462: Global name too long, shortened from: _GE_ERATORDYNAMICSMANAGER$generatordynamicsmanager_mp_setupgeneratorcontrolstatemanager$BLK..T1620_ to: _ERATORDYNAMICSMANAGER$generatordynamicsmanager_mp_setupgeneratorcontrolstatemanager$BLK..T1620_

^

There is another public item in that module:

FuncDetermineCWMdotForInternalFlowControl

which is longer than SetupGeneratorControlStateManager but does not generate a warning

One is a subroutine and one is a function in the code.

Linda

[IanH]

I get the warning if I compile the two files attached here (ExcelCOM.f90 is a Fortran Module wizard output file, that may have had an edit or two - I've not tried to cut it down at all).

The pre-requisites for the warning are pretty convoluted - in this specific case it involves things that are very "logically distant" from the source being compiled with the long symbol (e.g. a module that isn't used at all).

ExcelCOM.f90

ThirtyTwoCharactersInAModuleName.f90

[plain]>ifort /c ExcelCOM.f90 ThirtyTwoCharactersInAModuleName.f90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 1
2.0.0.104 Build 20101006
Copyright (C) 1985-2010 Intel Corporation.  All rights reserved.

ThirtyTwoCharactersInAModuleName.f90(1): warning #5462: Global name too long, sh
ortened from: __HIRTYTWOCHARACTERSINAMODULENAME$THIRTYTWOCHARACTERSINAMODULENAME
_mp_SIXTEENCHARSPROC$BLK..T101_ to: _HIRTYTWOCHARACTERSINAMODULENAME$THIRTYTWOCH
ARACTERSINAMODULENAME_mp_SIXTEENCHARSPROC$BLK..T101_

^[/plain]

[Steven_L_Intel1]

Thanks, Linda and Ian. I'll take a look at these.

[Martyn_C_Intel]

It seems to me that we have multiple issues here, we might want to split off a separate thread.

I have been able to construct a small test case to demonstrate the 12.0 compiler putting the module twice into certain symbol names. The problem has been escalated to the compiler developers.
Linkers impose a maximum length on symbol names. For long module names, the duplication may cause the symbol name to exceed the maximum length, and the compiler may need to truncate, starting from the front. Since it is the duplicate name that gets truncated, I don't think there is any danger of name conflicts, except in extreme cases that would also have been a problem in the 11.1 compiler. Therefore, if you don't like the plethora of warning messages, you could disable them with /Qdiag-disable:5462.
We'll let you know if/when there's a compiler update with a fix for the duplication of the module name in some symbol names.

[kferrio]

Thank you, Martyn.

Is it possible for Intel to offer any general guidance on the length of module names? I expect there will always be a limit, imposed by the linker if nothing else. So I don't expect a magical fix. But some bounds for my more "poetic" developers would be helpful.

[Steven_L_Intel1]

The linker limits global names to 63 characters, so try to keep the combination of module names and identifier names to under 55 or so.

[Steven_L_Intel1]

I can see the warning with Ian's source, but not with Linda's, using 12.0 Update 1.

[lklawrie]

I'm still getting it in my actual compile but maybe not as many?

I still have the beta on a different machine that I could try to see if there are less or more.

Linda

[Steven_L_Intel1]

That's not necessary at this time, Linda, thanks. We do have a sample that seems to generate a problem where it shouldn't.

[kferrio]

Thanks, Steve. One of my "composers" is probably apporaching that limit, so we'll be careful.

[Steven_L_Intel1]

Fixed in 12.0 Update 3.