warning #5462: Global name too long, shortened from... side effects?

[Johannes_Rieke]

Hi all,

I begin to write my new code parts by using submodules and got a warning during compilation that the 'global name' is too long:

warning #5462: Global name too long, shortened from: MOD_CALC_BEAM_SOLUTION@SMOD_CALC_BEAM_SOLUTION_ANALYTICALCALC_BEAM_SOLUTION_ANALYTICAL_mp_R1NX to: _CALC_BEAM_SOLUTION@SMOD_CALC_BEAM_SOLUTION_ANALYTICALCALC_BEAM_SOLUTION_ANALYTICAL_mp_R1NX

The original name is 94 characters long the shortened version 91. I wonder that and why such a limitation still exist, because I try to give meaningful (file-)names for all my code parts, thinking this is a good programming praxis. Luckily PSXE 2016 update 3 gives no error as older 12.x has done (https://software.intel.com/en-us/comment/1826536#comment-1826536)

However, the program works fine. Have this shortening of the global name any side effects? Maybe in relation with interoperability? Should I use shorter names?

Best regards, Johannes

ps: some code snippets:

submodule (mod_calc_beam_solution) smod_calc_beam_solution_analytical

  contains
  module subroutine calc_beam_solution_analytical
    use mod_PRoSiT_parameter
    implicit none
  
  end subroutine calc_beam_solution_analytical
  
end submodule smod_calc_beam_solution_analytical


module mod_calc_beam_solution
  implicit none
  
  private
  public  :: calc_beam_solution_analytical
  public  :: calc_beam_solution_GEBT
  
  ! --------------------------------------------------------------------------------
  
  interface 
    module subroutine calc_beam_solution_analytical
      implicit none
    end subroutine calc_beam_solution_analytical
  end interface
  
  
  interface 
    module subroutine calc_beam_solution_GEBT
      implicit none
    end subroutine calc_beam_solution_GEBT
  end interface
  
end module mod_calc_beam_solution

[Steven_L_Intel1]

It's a restriction of the Microsoft object language in how long a global name can be. As long as the name doesn't conflict with another name, there is no effect.

[Johannes_Rieke]

Hi Steve,

thanks for the information. So it is really harmless. Nevertheless, it's a pity that Microsoft have this limit. I'm eager to know what on Linux will happen.

Regards, Johannes

[Steven_L_Intel1]

Linux doesn't have this restriction, though our compiler currently believes it does. Issue DPD200381747 was filed to ask that this be corrected.

What I find interesting about your example is that the shortened name is 91 characters. The Windows limit on global names is 63 characters. Submodules further lengthen global names and we may not be applying the limit correctly here. I'll do some tests.

[Steven_L_Intel1]

Looking closer at your example and error messages, I am puzzled. The source doesn't demonstrate the problem and the name you give in the error message seems to duplicate part of the name. Would you please attach a compilable source that demonstrates the problem?

[Johannes_Rieke]

Hi Steve, interesting.

I have build a small project to show the warning, but I cannot invoke the warning #5462 there. I will have to compare the (diagnostic) settings... (both x64 release...)

[Johannes_Rieke]

Took me some time to get it working. The trick is that the real parameter value r1nx have to be present in the submodule routine. I assume that this parameter gets implicitly the save attribute and then the global name gets too long. Please, look into the attached zipped solution.

submodule (mod_calc_beam_solution) smod_calc_beam_solution_analytical
  contains
  module subroutine calc_beam_solution_analytical
    use mod_parameter
#if defined(_WIN32) || defined(_WIN64)
    use mod_io_win
#elif defined(__linux__)
    use mod_io_lin
#endif
    implicit none       
    real(rk),parameter :: r1nx(3)=[1.0_rk, 0.0_rk, 0.0_rk] ! this is the variable, which invokes the warning #5462
    real(rk)           :: foobar_real_value
    
    write(*,'("FOO")') 
    
    foobar_real_value = 1.0_rk
    
    return
  end subroutine calc_beam_solution_analytical  

end submodule smod_calc_beam_solution_analytical

1>------ Rebuild All started: Project: long_names_issue, Configuration: Release x64 ------
1>Deleting intermediate files and output files for project 'long_names_issue', configuration 'Release|x64'.
1>Compiling with Intel(R) Visual Fortran Compiler 16.0 [Intel(R) 64]...
1>mod_calc_beam_solution.f90
1>mod_io_win.f90
1>mod_io_lin.f90
1>mod_parameter.f90
1>smod_calc_beam_solution_analytical.f90
1>mod_long_name_dummy_some_text.f90
1>smod_calc_beam_solution_GEBT.f90
1>D:\02_Fortran\99_test\long_names_issue\smod_calc_beam_solution_analytical.f90(11): warning #5462: Global name too long, shortened from: MOD_CALC_BEAM_SOLUTION@SMOD_CALC_BEAM_SOLUTION_ANALYTICALCALC_BEAM_SOLUTION_ANALYTICAL_mp_R1NX to: _CALC_BEAM_SOLUTION@SMOD_CALC_BEAM_SOLUTION_ANALYTICALCALC_BEAM_SOLUTION_ANALYTICAL_mp_R1NX
1>long_names_issue.f90
1>Linking...
1>Embedding manifest...
1>
1>Build log written to  "file://D:\02_Fortran\99_test\long_names_issue\x64\Release\BuildLog.htm"
1>long_names_issue - 0 error(s), 1 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

[Steven_L_Intel1]

Ok, thanks - I used this to construct a standalone example. The compiler has to combine the module name, submodule name, procedure name and local identifier name. It needs a global for the PARAMETER because it's array-valued. If it was just a scalar (and not derived or character type), there would not need to be global storage for it.

The thing that puzzles me is the way this combining was done. There's no delimiter between the submodule name and the procedure name, which looks strange. It works as long as the compiler is consistent with what it does, but I will ask the development team if this is really what was intended. (It also puzzles me that this constructed name is as long as it is, since I thought the Windows maximum length was shorter.

Edit: It's combining what would be the global name for the routine with the module name and submodule name. On IA-32 the routine name would have an underscore prefix, on Intel 64 no underscore. That's why it looks odd on Intel 64.

[jimdempseyatthecove]

Can the compiler hash the long names and then use an alias?

Jim Dempsey

[Steven_L_Intel1]

We thought of that, but it really gets messy if you want to call these from other languages. We haven't yet seen a real problem caused by the shortening, though of course one could construct an artificial problem case.