Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28546 Discussions

What is the max. number of characters for a symbol for Intel ifort/ifx compilers?

OP1
New Contributor II
2,183 Views

The fortran standard (since 2003 I believe) says that symbols can have a maximum of 63 characters. Today I realized that the intel fortran compilers accept symbols with more than 63 characters (the warning #6439 is issued in that case).

It's a bit of an academic question (although with type-bound procedures in deep parent-children derived-type genealogies it is not uncommon to end up with long procedure names...), but what is the actual limit for the fortran compiler?

I tried to locate this information in the documentation but couldn't find anything.

0 Kudos
15 Replies
Steve_Lionel
Honored Contributor III
2,167 Views

Intel documents the limit as 63 characters. You get an error, not a warning, if you exceed that.

t.f90(1): error #6439: This symbol has too many characters.   [A234567890123456789012345678901234567890123]
integer :: A234567890123456789012345678901234567890123456789012345678901234567890123456789 = 4
-----------^

I'll comment that even at the standard limit, you can run into linking problems if you use modules with long names combined with identifiers that have long names, as on some platforms there is a hard limit on the length of a global symbol.

Compiler Limits (intel.com)

0 Kudos
OP1
New Contributor II
2,156 Views

@Steve_Lionel , this is strange, because with ifort 2021.6.0 I do get a warning, not an error - and the program builds and runs just fine:

PROGRAM P
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER :: A_1000000000100000000010000000001000000000100000000010000000001000000000 = 1
WRITE(*, *) A_1000000000100000000010000000001000000000100000000010000000001000000000
END PROGRAM P

Now, the program above was built with /stand:f18 and I got a warning. If I do not use this option, then I get the error as you said. I am not sure if any of this makes sense.

0 Kudos
JohnNichols
Valued Contributor III
2,146 Views

A bit aside:

But when I was trying to run some code from GITHUB, it kept complaining about long names.  

0 Kudos
JohnNichols
Valued Contributor III
2,142 Views

If you take a variable with 63 elements in the name and there are say 30 different characters for each element, you could give every proton, neutron and electron a unique name for all of the earths chemicals, and have names left over.  

Of course you run out of memory. 

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,132 Views

@OP1  this is what I get:

D:\Projects>ifort -c t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

t.f90(3): error #6439: This symbol has too many characters.   [A_10000000001000000000100000000010000000001]
INTEGER :: A_1000000000100000000010000000001000000000100000000010000000001000000000 = 1
-----------^
compilation aborted for t.f90 (code 1)
0 Kudos
OP1
New Contributor II
2,125 Views

Steve, if you use the following command:

ifort -c -stand:f18 t.f90

you will get the warning instead of the error. I'd be tempted to say this is a compiler bug?

0 Kudos
Steve_Lionel
Honored Contributor III
2,117 Views

It's certainly not the behavior I would expect. More interesting is that it DOES allow more than 63 characters as long as you have asked for standards checking. This is not how it's supposed to work. I tried to see what the maximum really was but haven't encountered it yet (I tested up to 200.) It's not just discarding characters, either - it can distinguish two very long names that differ in the last character.

0 Kudos
OP1
New Contributor II
2,107 Views

Yes, I observed this as well - it's as if the 63-character limit is ignored and the code works even with really long symbols (and as you observed, they are not truncated, which would introduce a risk of collision otherwise). It only works this way for -stand:f18; for other standards the compiler issues an error.

Maybe this is an undocumented compiler 'extension' (pun non-intended) of the standard, ha ha. @Barbara_P_Intel may be able to investigate if this is a compiler bug or not (sorry for keeping you busy Barbara!).

0 Kudos
Steve_Lionel
Honored Contributor III
2,089 Views

I will comment that /stand is not ever supposed to change the compiler's behavior - it is only to enable diagnostics. Unlike some other compilers (gfortran for example), ifort doesn't have "standard version" modes (though it does have options that control selected behaviors.)

In addition to the inappropriate side-effect of requesting standards diagnostics, the documentation should be updated to state the compiler's actual limit on identifier length.

I've attached a test source, and here's what I get when I compile/link it.

D:\Projects>ifort t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

t.f90(3): error #6439: This symbol has too many characters.   [A_10000000001000000000100000000010000000001]
INTEGER :: A_1000000000100000000010000000001000000000100000000010000000001000000000 = 1
-----------^
t.f90(4): error #6439: This symbol has too many characters.   [A_10000000001000000000100000000010000000001]
INTEGER :: A_1000000000100000000010000000001000000000100000000010000000001000000001 = 2
-----------^
compilation aborted for t.f90 (code 1)

D:\Projects>ifort /stand:f18 t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

t.f90(3): warning #6439: This symbol has too many characters.   [A_10000000001000000000100000000010000000001]
INTEGER :: A_1000000000100000000010000000001000000000100000000010000000001000000000 = 1
-----------^
t.f90(4): warning #6439: This symbol has too many characters.   [A_10000000001000000000100000000010000000001]
INTEGER :: A_1000000000100000000010000000001000000000100000000010000000001000000001 = 2
-----------^
Microsoft (R) Incremental Linker Version 14.31.31107.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
           1
           2
0 Kudos
Barbara_P_Intel
Employee
2,049 Views

@OP1  Thanks for keeping me busy.  This one is twisting my head a bit. Seems like -stand is taking precedence. I think it's a bug.

You know, in the Developer Guide regarding -stand, it says

 

When you specify this option, things that are not provided for in the Fortran standard at the specified standard level are diagnosed with warnings - this includes compiler directives recognized by ifort.

These standard compliance warnings can be ignored as they are informational only and do not affect compilation.

 

So the compiler IS doing that.   

Bug ID CMPLRIL0-34737

0 Kudos
Steve_Lionel
Honored Contributor III
2,016 Views

My friends in the Fortran development team tell me that the number shall be 63. 64 is right out. That asking for standards checking turns this into a warning is a bug.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,987 Views

Steve,

Does the 63 characters include the name decorations for module/save variables (xxx_mp_module/xxx_procedureName)?

Or does it only apply to the program visible name?

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
1,968 Views

I understand all of the comments, so far, and I feel sorry for Barbara, but if some one is using 63 character names then they had better turn on implicit none.  

Why did they pick 63, it is not a number that stands out in your mind, like 20, 50 , 72 or 100?  Someone has to have put some thought into this?  Does anyone know?  Why do we need the limit? 

0 Kudos
Steve_Lionel
Honored Contributor III
1,966 Views

63 characters is the limit for individual identifiers in the source. As I have noted before, some linkers have limits on global symbol size so even if you use all standard-conforming lengths, there could be issues building the program. The compiler does some "abbreviation" of long decorated names in hopes of avoiding issues, but it's always possible to construct a case that doesn't work. 

Note that the standard explicitly does not specify "the size or complexity of a program and its data that will exceed the capacity of any particular computing system or the capability of a particular processor".

 

As for why 63? There's a long history of limits relating to powers of two, even though this doesn't make a lot of sense nowadays. And for something that certainly no longer makes sense, consider the free-form line length of 132 characters (the length of a line printer line) - this changes to 10,000 (see! Not a power of two!) in Fortran 2023. F2023 also removes the limit on free-form continuation lines, but does impose a limit of 1,000,000 on the total number of characters in a statement.

Limits are there because having everything unlimited unreasonably complicates compilers. It has been a topic of heated discussion among the committee at times.

0 Kudos
Barbara_P_Intel
Employee
1,661 Views

The error that turned into a warning when compiling with "-stand f18" is fixed in the latest compiler release, ifort 2021.7.0 and ifx 2022.2.0. Both compilers are part of the oneAPI HPC 2022.3 Toolkit.

Have you tried it?



0 Kudos
Reply