forrtl: severe (193): Run-Time Check Failure.

[daldystultz]

Hi Intel world:

My last problem was solved so quickly on this forum, I'm daring to try again!

Compiling about 250 subroutines with statements like:

ifort -c -o mskip.o -g -check -fpe1 -m32 mskip.f

and then linking them all with the statement

ifort -o xdzeus36 -m32 mskip.o ...(plus 250 more)... ...(plus libraries compiled with -O2 and no checking on)

I get the runtime error:

forrtl: severe (193): Run-Time Check Failure. The variable 'roe_$ASL' is being used without being defined

What is ifort trying to tell me here? There is *no* variable anywhere in the 100,000 lines of code called roe_$ASL. I never use dollar signs nor underscores in any of my variable names. Now, there is a subroutine (not a function) called roe, and that is the closest thing I can see that resembles the variable ifort is making up. BTW, when run under -O2 with no traps set, the code runs fine.

Any ideas? Thanks.

Cheers, David.

[Ron_Green]

Quoting - daldystultz

Hi Intel world:

My last problem was solved so quickly on this forum, I'm daring to try again!

Compiling about 250 subroutines with statements like:

ifort -c -o mskip.o -g -check -fpe1 -m32 mskip.f

and then linking them all with the statement

ifort -o xdzeus36 -m32 mskip.o ...(plus 250 more)... ...(plus libraries compiled with -O2 and no checking on)

I get the runtime error:

forrtl: severe (193): Run-Time Check Failure. The variable 'roe_$ASL' is being used without being defined

What is ifort trying to tell me here? There is *no* variable anywhere in the 100,000 lines of code called roe_$ASL. I never use dollar signs nor underscores in any of my variable names. Now, there is a subroutine (not a function) called roe, and that is the closest thing I can see that resembles the variable ifort is making up. BTW, when run under -O2 with no traps set, the code runs fine.

Any ideas? Thanks.

Cheers, David.

2 thoughts to try:

first, compile and link with -g -traceback and then run. It will tell you where in the source code this failure occurs.

Next, try compiling and linking with -gen-interfaces -warn interfaces

that might help indentify if you've used the subroutine in the context of a function call.

ron

[mrentropy1]

Hey, I'm learning....

From the looks of it, best to ignore me and take the advice of the experts! Thanks, Ron.

Peter

[daldystultz]

Quoting - Ronald W. Green (Intel)

2 thoughts to try:

first, compile and link with -g -traceback and then run. It will tell you where in the source code this failure occurs.

Next, try compiling and linking with -gen-interfaces -warn interfaces

that might help indentify if you've used the subroutine in the context of a function call.

ron

Thanks Ron. I wasn't aware that Intel FORTRAN didn't do tracebacks automatically: it's the first compiler I've come across in 25 years that doesn't.

I also learned that the syntax it uses to report variables is: function_$variable, with the function in lower case, and the actual variable in upper case. Thus, when it said "variable roe_$ASL is undefined", what it meant was that variable asl in subroutine ROE was undefined, which indeed it was.

These are two items all new users to Intel FORTRAN should know. Is there a 5-10 page intro to Intel FORTRAN that would have such details in it? You know, something written for FORTRAN users familiar with other compilers, but just need to know the syntax and peculiarities of Intel's brand, along with a quick description of the 5% of the options that get 95% of the use? The man pages are a definite deterrent; long long long, and impossible to find what you want.

Last thing, I find the Intel compiler to be incredibly *slow*. I'm not talking about the executable it generates, I am talking about how long the compiler takes to compile, even with all the optimisation turned off. It is at least an order of magnitude slower than gfortran, for example. Is there a reason for this?

Thanks again.

Cheers, David.

[Ron_Green]

Quoting - daldystultz

Thanks Ron. I wasn't aware that Intel FORTRAN didn't do tracebacks automatically: it's the first compiler I've come across in 25 years that doesn't.

I also learned that the syntax it uses to report variables is: function_$variable, with the function in lower case, and the actual variable in upper case. Thus, when it said "variable roe_$ASL is undefined", what it meant was that variable asl in subroutine ROE was undefined, which indeed it was.

These are two items all new users to Intel FORTRAN should know. Is there a 5-10 page intro to Intel FORTRAN that would have such details in it? You know, something written for FORTRAN users familiar with other compilers, but just need to know the syntax and peculiarities of Intel's brand, along with a quick description of the 5% of the options that get 95% of the use? The man pages are a definite deterrent; long long long, and impossible to find what you want.

Last thing, I find the Intel compiler to be incredibly *slow*. I'm not talking about the executable it generates, I am talking about how long the compiler takes to compile, even with all the optimisation turned off. It is at least an order of magnitude slower than gfortran, for example. Is there a reason for this?

Thanks again.

Cheers, David.

Points well taken.

Getting started: For the next major version of the compiler we will revisit the whole 'startup experience' and documentation to make it easier to find the most relevant information. Yes, a list of the 'top 10' or 20 compiler options for new users would be a valuable addition to this getting started document, taken from the perspective of a user who is familiar with other compilers but new to Intel Fortran.

Slow compilation: We have seen issues in the past in 2 major areas: complex nesting of interdependent module USE, and secondly in codes with large data initialization (block data or just a huge number of compile-time initializations).

And when you say 'optimization turned off' you mean you explicitly set -O0, correct? Because without a -Ox option the default is -O2 which is quite aggressive for this compiler.

ron

[daldystultz]

Quoting - Ronald W. Green (Intel)

Points well taken.

Getting started: For the next major version of the compiler we will revisit the whole 'startup experience' and documentation to make it easier to find the most relevant information. Yes, a list of the 'top 10' or 20 compiler options for new users would be a valuable addition to this getting started document, taken from the perspective of a user who is familiar with other compilers but new to Intel Fortran.

Slow compilation: We have seen issues in the past in 2 major areas: complex nesting of interdependent module USE, and secondly in codes with large data initialization (block data or just a huge number of compile-time initializations).

And when you say 'optimization turned off' you mean you explicitly set -O0, correct? Because without a -Ox option the default is -O2 which is quite aggressive for this compiler.

ron

Hi Ron:

Sigh; so many vendors seem to have the same reaction to my suggestion of a quick get-up-and-go to their software for the new, but experienced user: "Good idea, haven't done it yet." Totalview, for example, has 1200 freakin' pages of manuals that we're supposed to read and digest, as though we have nothing else to do than read their bloody documents. After I finally figured out how to use the thing (with a lot of hand-holding over the phone and e-mail by a very patient tech support person), I boiled down these 1200 pages to about three or four pages of essentials that a new user familiar with debugging in general, but not totalview's brand needs to know. This is what I now refer to. Now why I can do this, and these multi-gazillion $ firms can't, I cannot fathom. I guess it isn't the "style" anymore to be user-friendly. Even Apple has gone user-hostile. Ever try to use XCode? Talk about documentation nightmare...

By no optimisation, I mean -g. Does that still hold on to -O2? Again, most compilers include -O0 in their -g. Another item for the quick start-up-manual perhaps? :-)

Cheers, David.

[mrentropy1]

Quoting - daldystultz

Hi Ron:

Sigh; so many vendors seem to have the same reaction to my suggestion of a quick get-up-and-go to their software for the new, but experienced user: "Good idea, haven't done it yet." Totalview, for example, has 1200 freakin' pages of manuals that we're supposed to read and digest, as though we have nothing else to do than read their bloody documents. After I finally figured out how to use the thing (with a lot of hand-holding over the phone and e-mail by a very patient tech support person), I boiled down these 1200 pages to about three or four pages of essentials that a new user familiar with debugging in general, but not totalview's brand needs to know. This is what I now refer to.

< snip >

Cheers, David.

Hey, cool, I use TotalView too! I could really use that info - care to share????

[mrentropy1]

Quoting - Ronald W. Green (Intel)

And when you say 'optimization turned off' you mean you explicitly set -O0, correct? Because without a -Ox option the default is -O2 which is quite aggressive for this compiler.

ron

Now THAT is handy to know.....

[Ron_Green]

Quoting - mrentropy

Now THAT is handy to know.....

-g does imply -O0. From the -g documentation:

"This option turns off O2 and makes O0 (Linux and Mac OS X) or Od (Windows) the default unless O2 (or another O option) is explicitly specified in the same command line."

[Anand_T_]

Hi David,

I am running to the very same problem with Zeus. How did you end up ixing the roe_$ASL undefined variable problem. I looked into roe.f and it seems that asl is defined fine. As a result I am not sure what is going on.

Thank you,

Anand

[Anand_T_]

i have the same error. how did you manage to fix it?

[Anand_T_]

FIX #1

------------

There is an unused and uninitialised variable in subroutine ROE call asl that is causing the problem.  Most compilers don't fret over such uninitialised variables; ifort seems to.

The easiest fix is just to delete the statement

al = sqrt ( asl )

and also eliminate both al and asl from the variable declaration list in the real*8 statement above.  I guess these are variables Ryu and Jones required at one time, but fell from use and ended up as the vesitge they are.

You may find similar types of errors crop up in *gp riemann; their fix is similar.

FIX #2:

---------------

As an alternative to David's fix outlined above, one could also do the following: 

Where the variable is declared as real*8 just tell the fortran compiler to save the variable from one call to the next, with:

real*8 save :: asl, al. ... , [any other variables in this list in subroutine roe]

A similar error crops up with variables bperpl, bperpm and bperpr in subroutie simpler, the fix is the same, to save the variables. 

Hope this helps.