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
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.
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.
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?
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...)
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 ==========
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.
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.