Recursive subroutine problem with compiler options

[caddymj]

I have converted from CVF a code that uses subroutines that are "recursive subroutine ......." but the only way I can get it to work is to set the compiler option to recursive which appears to defeat the static variable storage using the /Qsave feature. All worked just fine in CVF. Using IVF 11.x version 9.x appears to work just fine. Is this bug or what settings do I need to use?

[Jugoslav_Dujic]

Quoting - caddymj

I have converted from CVF a code that uses subroutines that are "recursive subroutine ......." but the only way I can get it to work is to set the compiler option to recursive which appears to defeat the static variable storage using the /Qsave feature. All worked just fine in CVF. Using IVF 11.x version 9.x appears to work just fine. Is this bug or what settings do I need to use?

Which 11.x exactly?

There was a bug between, roughly, 11.0. and 11.0.066, fixed some time later (072? Steve would probably know the exact date, i could dig out my Premier correspondence). The details match yours, and are in more detail explained here. The bottom line is that /Qsave overrides RECURSIVE although it shouldn't. Luckily, I didn't need /Qsave, so I just got rid of it.

The obvious workaround is to use a newer compiler. A still better workaround is to get rid of /Qsave and put in blank SAVE statement to all routines that need it, which has the additional bonus of making the code standard-conforming and portable.

[Steven_L_Intel1]

Jugoslav is correct. This bug was fixed in version 11.1.

[Paul_Curtis]

Quoting - Jugoslav Dujic

... get rid of /Qsave and put in blank SAVE statement to all routines that need it, which has the additional bonus of making the code standard-conforming and portable.

I also had this problem. However, /Qsave is the default (no compiler flag needed) in CVF, MS, CDC, VAX, HP and every other Fortran I've ever seen. Nothing wrong with a liberal dose of SAVE statements, but perhaps IVF should reset their default to be standard-conforming, in which case /Qsave would no longer be needed.

[Jugoslav_Dujic]

Quoting - Paul Curtis

I also had this problem. However, /Qsave is the default (no compiler flag needed) in CVF, MS, CDC, VAX, HP and every other Fortran I've ever seen. Nothing wrong with a liberal dose of SAVE statements, but perhaps IVF should reset their default to be standard-conforming, in which case /Qsave would no longer be needed.

On the contrary, I claim that the current way is much better. A standard-conforming program must behave the same regardless of whether the default storage is static (/Qsave) or automatic (Ifort default). Default SAVE semantics tend to hide the problem of illegal code, though. /Qsave is an ugly patch for dusty deck codes that would better be fixed.

Besides, Intel being a chief promoter of parallel computing, it would be akin to shooting themselves in the foot to leave in the default compiler switch which activelly hampers parallelization and reentrance.

[Steven_L_Intel1]

I'll disagree that so many compilers default to /Qsave - certainly many older compilers did. But a problem is that /Qsave goes further than it should for CVF compatibility - it also forces local ALLOCATABLE variables to SAVE, which CVF didn't do and isn't what you generally want. I've asked that this be addressed, though I don't know exactly what the solution will be.

IVF's default IS standard-conforming - your code is not.

I agree with Jugoslav that relying on default SAVE semantics is bad, as such programs are relying on non-standard behavior. If you need SAVE, say SAVE.

[lklawrie]

I agree with Steve and Jugoslav on this issue. Painful sometimes but better overall.

Linda

[caddymj]

Quoting - Jugoslav Dujic

Which 11.x exactly?

There was a bug between, roughly, 11.0. and 11.0.066, fixed some time later (072? Steve would probably know the exact date, i could dig out my Premier correspondence). The details match yours, and are in more detail explained here. The bottom line is that /Qsave overrides RECURSIVE although it shouldn't. Luckily, I didn't need /Qsave, so I just got rid of it.

The obvious workaround is to use a newer compiler. A still better workaround is to get rid of /Qsave and put in blank SAVE statement to all routines that need it, which has the additional bonus of making the code standard-conforming and portable.

[caddymj]

Quoting - caddymj

Wow I am impressed with the support. thanks to everyone.
I work for the Navy and we purchased 6 licenses 11.0 Pro Editon with full visual studio 2008. These were loaded early this year. What is the best way to upgrade to a later version IVF with the bug fixed?

With regard to static variables, I agree with Steve, this has been around along time. My experience has been that Fortran with its static variables in some cases executes much faster that some of the object oriented codes. Yes, executibles are larger, but in some cares all the swaping slows codes.

caddymj

[Steven_L_Intel1]

If you bought earlier this year, just log in to the Intel Registration Center and you should be able to download 11.1. A noite of caution - there is a bug on that web site in that if your license was purchased for 11.0 and you click on a link that says 11.1, it will take you to an 11.0 page. Just go to the version selector dropdown about halfway down the page and select 11.1.

Static storage can sometimes be faster, but sometimes not. On the whole, not assuming SAVE semantics allows better optimizations which is why Intel Fortran doesn't do this.

[caddymj]

Quoting - caddymj

I have converted from CVF a code that uses subroutines that are "recursive subroutine ......." but the only way I can get it to work is to set the compiler option to recursive which appears to defeat the static variable storage using the /Qsave feature. All worked just fine in CVF. Using IVF 11.x version 9.x appears to work just fine. Is this bug or what settings do I need to use?

I upgraded to IVF11.1 build 038 and so far regression testing shows new compiler fixed problem.
Used /Qsave option and turned off recursion compiler option. (subroutines in code were identifed with "recursive" flag in front of subroutine name.
Thanks

caddymj

[caddymj]

Quoting - caddymj

I have converted from CVF a code that uses subroutines that are "recursive subroutine ......." but the only way I can get it to work is to set the compiler option to recursive which appears to defeat the static variable storage using the /Qsave feature. All worked just fine in CVF. Using IVF 11.x version 9.x appears to work just fine. Is this bug or what settings do I need to use?

Now that I think I have this problem solved. I have re-read some of the other comments.
Getting away from /Qsave is probably a good idea, but very painful,code is too big. In a new code, yes.

I can recall moving DEC VMS code over to CDC Cyber 6600 (Bill Gates was in high school). The CDC 64 bit compilerhad a nasty of setting all undefined variables to NaN. With that setting many problems were discoveredin VMS codes, where engineers were using variables that were defaulted to zero automatically and they did not even know it. It was painful using the CDC codes to find these problems as one had to learn how to ready assembly dumps, No debuggers as we have today. The end result was that the CDC compiler produced better code and found lots of bugs. Isee that IVF has settings to help find these kinds of problems.