Conditional expression evaluation from Compaq to IVF

[nick6]

Hi,

We've got some code that is being migrated from compaq 6.6 to IVF;

IF (IASK.GE.4 .AND. XUPL_SSTA($MIN,INUM).GT.XUPL_SSTA($MAX,INUM)) THEN

    RTMP=XUPL_SSTA($MIN,INUM)

    XUPL_SSTA($MIN,INUM)=XUPL_SSTA($MAX,INUM)

    XUPL_SSTA($MAX,INUM)=RTMP

ENDIF

It appears that running the program compiled using Intel changes the conditional order. It's checking UPL_SSTA($MIN,INUM).GT.XUPL_SSTA($MAX,INUM) before IASK.GE.4 and crashing as it's access a zero element. There's a number of these situations failing.

Is there any way to resolve this without changing the code everywhere?

Cheers, Nick.

[mecej4]

You are asking for an option to perpetuate non-standard behavior; you can read in the Intel Fortran, for example, that "You should not write logical expressions whose results might depend on the evaluation order of subexpressions. The compiler is free to evaluate subexpressions in any order." Elsewhere, you will find it stated that variables that occur in expressions must be defined (in the Fortran sense) when the statement containing the expression is encountered.

Bite the bullet and fix the code.

[andrew_4619]

mecej4, you are 100% correct in what you say but if I had a bucket load of legacy code that relied in logical expressions being evaluated in the order coded I would give thanks and praises to a compiler option that made it happen that way if required.

[rase]

@app4619: I think it is not acceptable to allow a compiler to leapfrog contradictions to the standard which a very outdated compiler did not catch. I was in the same situation some time ago, and I was forced to correct a lot of legacy code with similar constructs. But the corrections were less time-consuming than expected, and during the corrections I detected some logical errors which I never noticed previously.

[jimdempseyatthecove]

app4619,

The standard requires all portions of the logical expression(s) be evaluated but does not specify the order (mecej4 pointed this out). While an option to perform evaluations C-like (or CVF-like) would be handy for your, you are asking for an excuse to fix bad code. Your request is not totally unfounded as there are compatibility options for PowerStation, VMS and MS VS. An option /fcvf:IF might not be totally out of order to request, however this may induce unexpected errors.

Jim Dempsey

[mecej4]

app4619 wrote:

mecej4,... but if I had a bucket load of legacy code that relied in logical expressions being evaluated in the order coded I would give thanks and praises to a compiler option that made it happen that way if required.

I recognize the situation. However, I just checked what the CVF 6.6C Ref.Man. says, and found this under "Evaluation of Logical Expressions":

You should not write logical expressions whose results might depend on the evaluation order of subexpressions. The compiler is free to evaluate subexpressions in any order.

These two sentences are identical in the CVF and IFort reference manuals. Therefore, the option that was asked for would be for the purpose of replicating behavior that one could not count upon even if one continued to use the CVF compiler.

It would be nice if someone could show example code that contained two or more similar compound logical expressions that get different semantic treatment by the CVF compiler (with optimization turned on).

[andrew_4619]

Hi Jim I wasn't actually asking, I have no need for this feature, it was purely a hypothetical point. That being said there, must be a lot of code around that used to 'work'. There have been many instances in life where a quick fix rather than a 'proper solution' has by necessity been the order of the day. Lets not be 'pure-ist', IVF has many non-standard options....

[jimdempseyatthecove]

>>must be a lot of code around that used to 'work'....
most of the time by accident then fail unexpectedly (sometimes much later) at other times.

This is one of those "at other times".

Jim Dempsey

[Steven_L_Intel1]

Back when I worked on CVF. we'd get complaints that CVF evaluated logical expressions in a different order than (compiler X). As stated above, the standard allows a compiler to evaluate any logically equivalent expression, in any order and to any degree of completeness it wants. Any changes in optimizer logic, for example, can change the order.  CVF didn't always use a particular order - you just "got lucky" that it did what you wanted. It might not have in a different version or with different optimization options.

[andrew_4619]

I recall Microsoft Fortran 5.0 evaluated in order and droped out at the first available point, but then we were on 8086 processors and trying to fit our programs into 512K of memory.....

I think I will retreat before I get too badly beat up on this one..... As for the OP, there is some work to do!

[mecej4]

app4619 wrote "I think I will retreat before I get too badly beat up on this one".

You do not need to feel that way at all. Your comments have contributed to airing the issues involved, and the OP can see from the posts in this thread that others have trodden the same prickly path.

[jimdempseyatthecove]

I'm with mecej4, just about every FORTRAN programmer has run into this issue and it needs to be aired out periodically for the newcommers. You did a service to the readers of this forum. Keep it up. If you do some serious Googling search, you might find a FORTRAN LINT or other utility program that can detect such occurances (and possibly fix them to boot).

Jim Dempsey

[nick6]

Thank you everyone for the replies. I knew this was an issue for legacy CVF code, we were just hoping to avoid the cost of rewriting these conditions. Looks like theres only one way forward here though.

Cheers.

[TimP]

As far as I know, a compound conditional has always been an invitation to the compiler to look for the most efficient order of evaluation.  Even though the first f77 compiler translated .and. literally to C operator && without permutations, that could be used as a predictor only for compilers where you could take the time to view the translated C code.  A translation using & might be equally faithful to the original Fortran but would not involve defined shortcut evaluation.

[Steven_L_Intel1]

Tim, are you referring to g77?  That's pretty late in the set of F77 compilers. The "real" early F77 compilers generated object code directly.

[TimP]

Steve, f2c came even before g77.  This, and the fact that libf2c was incorporated into g77, led to the misconception sometimes raised that g77 also translated to C.

More relevant to this thread, g77 already broke the misconception of a direct relationship between Fortran and C interpretation of conditionals.  However, f2c could continue to coexist with g77.

Tim

[jimdempseyatthecove]

Nick>>IF (IASK.GE.4 .AND. XUPL_SSTA($MIN,INUM).GT.XUPL_SSTA($MAX,INUM)) THEN
TimP> a compound conditional has always been an invitation to the compiler to look for the most efficient order of evaluation.

In Nick's case, the "most efficient" happened by chance to be on the left side (integer compare less costly than other expression). Depending on what preceeded this statement, the "most efficient" route may change.

"...you've got to ask yourself one question: Do I feel lucky?"
Dirty Harry, Movie 1971

Jim Dempsey

[andrew_4619]

"...you've got to ask yourself one question: Do I feel lucky?" 

You been counting? Well, was it five logical constructs or was it six? Standards say five...