Using the Intel Fortran compiler on Windows the maximum number of DO and IF loops is set to 256. Is it possible to increase this limit?
Just to clarify: You want to know if it is possible to use more than 256 do / if statements like
! no more if / do here possible
I´d rather simplify the code.
Where did you see this limitation? i.e. is this documented or do you have a reproducer? Is this for nested levels or inline use or both?
If you have a simple reproducer, please attach to your reply.
I noted compiling a program developed on Linux. This limitation is declared in the
Intel® Fortran Compiler XE 13.1 User and Reference Guides/ Compiler Limits:
"DO and block IF statement nesting (combined) 256"
I am hoping that this limit can be overwritten
Ok, I see it there now.
Note though that this is for nested DO and IF blocks (combined). I've never seen a program requiring that high of nest level.
Array dimensions limit is 31, nest restrictions won't apply to this.
What you can do in this case is encapsulate and call the encapsulation at every 250 levels, or at an appropriate level to reduce arguments on call.
DO I1=1,nDO I2=1,n...DO I250=1,ncall DOI2512to500(yourArgsHere)END DO ! I250END DO ! I249...END DO ! I2END DO ! I1
A module can be used if you have a large number of variables to pass all the way down.
Out of curiosity, can you describe the program that exceeds this limitation?
As others have said, this is a limit on how many nested DO or IF blocks you can have. I have never seen a real program come even close to this limit. It is not a limit on the total number of DO or IF blocks you can have, nor a limit on the DO loop index.
It is possible with large source files to see optimization cut off without warning for some DO loops which would not normally require !dir$ SIMD. If this is a concern, you may need /Qopt-report or /Qvec-report. The bug with /Qopt-report not working along with other options such as /arch: is present in the 2013 update 3 and 4 releases, but vec-report should be OK.
I try to compile the atomic physics code, Grasp2K on Windows, when I noted the problem. The code was originally developed on Linux and using the Intel compiler no problem was noted.
I tried the /Qvec-repor1 compiler option as TimP suggested and the following error was reported:
"error #6370: The IF, DO, CASE, FORALL (if supported), and/or WHERE constructs are nested too deeply. The current limit is 256."
It is not practical to modify the code and I am wondering, if this limit can be increased. Looking the actual code a limit of ~350 should work.
If this code can be compiled at all, then I would guess that the error message is incorrect. Is this code something I can download freely, or can you attach the problem file here?
The code was published in Computer Physics Communication and it not supposed to be upload into the public domain. However I would apreciate if the problem can be further investigated.
I can't do anything without source. Please submit an issue to Intel Premier Support and attach the code - ask that it be assigned to me.
Ok, this source really does have more than 256 nested IF and DO constructs. 317 by my count. It is obviously a machine-generated source and I have to wonder if the creators really understand what it is doing. That said, it does not compile in any version of Intel Fortran to date. I have filed a feature request asking that the limit be raised, but I can't say when or if it will be implemented.
Can the code be encapsulate into a subroutine at say level 200 or so? The local variables could be placed into a module.
Or (Steve help), use of a procedure contained subroutine may get a new set of 256 levels.
I think moving some of the blocks into a contained routine might actually work - let me try that. There are hundreds of mechanically-named variables as well....
>>There are hundreds of mechanically-named variables as well....
Hope the contained routine works... 4 statements and a cut&paste to fix (plus the time necessary to find the matching ENDDO).The module route might take 7 statements and a cut&paste to fix (plus the time necessary to find the matching ENDDO).
Indeed, moving a chunk of the nested DO/IF to a contained routine that is then called allows the source to compile. I have sent Tibor the edited source.
Assuming the .f90/.f source is auto-generated, this conversion may be something he could automate using AWK, Perl or other scripting language (VB, ...).
Would there be an issue of having a contained routine, itself having a contained routine? (e.g. the program had 700 nest levels)
Given the restriction "Any number of internal procedures can follow a CONTAINS statement, but a CONTAINS statement cannot appear in the internal procedures themselves", I think that CONTAINS can only be nested 1-deep.
You would not need to nest the CONTAINs in this particular case, you could have a second contained routine called from the first.
Fortran 2008 defines submodules This has been mentioned several times on these forums. Apparently, only Cray Fortran supports this.
The nesting of the contains was mainly subject to reduction of complexity of AWK, Perl, ... script. I suppose if the script were written inside-out then one level of contains might not be so hard to impliment.
Submodules would not apply to this problem.
We're raising the block nesting level limit to 512 in a release later this year.