topic NaN - another why question? in Intel® Fortran Compiler

NaN - another why question?

jim_cox — Mon, 19 Oct 2009 02:31:14 GMT

Me again (sorry)

I have yet another issue - this time with parsing incoming data.

Using

EQUIVALENCE (FBUF(1),SFBUF)

and

READ(DAFIL,'(780A1)',ERR=2) (FBUF(J),J=1,780)

to get this line from a datafile

0112VT.000 24.61 19.17 125 011BNL.000 NORTH SHORE CITY - 2001 0500-0700 LOADED NETWORK

This read is correct

But then we try to break it down with

READ(SFBUF,149,ERR=2) (IDTRP(K,J),J=1,10),
* CCPM(K), CCPK(K), LOLNK(K), HILNK(K),
* (IDTIM(K,J),J=1,10), (CDESC(K,J),J=1,40),
* CSEL(K)
149 FORMAT(10A1,5X,2F6.0,2I2,5X,10A1,5X,40A1,1X,A1)

The values get correctly loaded in IDTRP (0112VT.000), CCPK(19.17), LOLNK(1) , HILNK(25) etc...

But CCPM gets NaN, not 24.61

And no error jump occurs

The datafile appears correctly formatted - exact same file works fine with the same code compiled under MS Powerstation.

What's going on here - am I missing something?

Thankx again

Jim

Edit: Have just found the paste function on this forum reformated the pasted data line - so have uploded the original (assign.par) Line 6 is the line in question.

Re: NaN - another why question?

bmchenry — Mon, 19 Oct 2009 14:37:35 GMT

What are the declarations for the various arrays, etc?
it appears that your read is correct for the attached data so it must be to some storage issue with the array that produces NaN.

Re: NaN - another why question?

jimdempseyatthecove — Mon, 19 Oct 2009 15:03:46 GMT

0112VT.000 24.61 19.17 125 011BNL.000 NORTH SHORE CITY - 2001 0500-0700 LOADED NETWORK
149 FORMAT(10A1,5X,2F6.0,2I2,5X,10A1,5X,40A1,1X,A1)

10A1 = "0112VT.000"
5X = " 24.6"
2F6.0 = "1 19.1", "7 125 "
...

Reading CCMP would terminate on the space following 1st 1. I am not sure why the input does not span all 6 character positions of F6.0. Maybe that is part of "undefined behavior" or "defined behavior". Steve would know.

Your problem is the 1st 5X.

Jim Dempsey

Re: NaN - another why question?

Steven_L_Intel1 — Mon, 19 Oct 2009 15:46:00 GMT

When the comma is read the read of the variable is ended due to an extension called "short field termination".

Re: NaN - another why question?

jim_cox — Mon, 19 Oct 2009 20:00:48 GMT

Quoting - Steve Lionel (Intel)

When the comma is read the read of the variable is ended due to an extension called "short field termination".

Sorry? Which comma?

How do switch the "short field termination" off?

Thankx

Jim

=mjc=
.

Re: NaN - another why question?

Steven_L_Intel1 — Mon, 19 Oct 2009 20:26:34 GMT

Please ignore what I wrote previously - I misunderstood the situation. Let me look at it again and see what the issue Jim raised was.

Re: NaN - another why question?

Steven_L_Intel1 — Mon, 19 Oct 2009 20:45:23 GMT

I constructed a test case based on what you showed and it works for me. Perhaps Jim miscounted characters. I don't see how one could get a NaN from a formatted READ, unless what you read was "NaN". Since you have shown us a fragment only and not a complete program, I'm left to conclude that what you have not shown us is important. The only odd thing is that the read of CDESC pulls in only part of what looks like a text string at the end of the record and CSEL just has a the N of "NETWORK".

I've attached my test case. Please attach yours.

Re: NaN - another why question?

jim_cox — Mon, 19 Oct 2009 23:22:13 GMT

Quoting - Steve Lionel (Intel)

I've attached my test case. Please attach yours.

Steve, please try the attached - I've cut down the original code as far as possible.

Main routine is READTEST.F

Problem is evident at line 377 of ASSPAM.F when it reads line 6 of ASSIGN.PAR when CCPM(1) comes back as NaN

Hopefully I've included all the .lib files needed to link.

Set up is little tricky as the program will look for TRACKS.DAT and expects to write to SITE.TRX somewhere in the path.

Expect the program to stop the end of asspam as I have not given you all the datafiles expected.

Hopefully you can see the compiler settings I'm using

Thankx yet again for your help

Jim

Re: NaN - another why question?

Steven_L_Intel1 — Tue, 20 Oct 2009 00:20:20 GMT

Sorry - this is a bit more complex than I'm willing to look at at this point. You should be able to come up with a test case about the same size as mine.

Re: NaN - another why question?

jim_cox — Tue, 20 Oct 2009 00:36:12 GMT

Quoting - Steve Lionel (Intel)

Sorry - this is a bit more complex than I'm willing to look at at this point. You should be able to come up with a test case about the same size as mine.

Sorry I thought you wanted an example where the weirdness was actually happening.

As it appears that minor changes to the program make a difference

For example

At line 83 in READTEST.F there is a call to a GAPINI routine which checks the program licensing

If I replace this call with GAPINI_FREE (no licence required) the ASSPAM read works correctly.

Re: NaN - another why question?

Steven_L_Intel1 — Tue, 20 Oct 2009 13:52:56 GMT

I wanted a small test case that showed the problem. You have evidently discovered that you probably have a bug elsewhere in the program that is manifesting itself as the NaN. Perhaps you're accessing off the end of an array or have an argument mismatch, or something else. Your program is a mix of Fortran and C++ and may also be corrupting the stack with mismatched calling conventions. I have not studied it in detail to know. In any event, the issue is not directly related to the READ, which is why excerpts of programs are usually not helpful in analyzing problems.

The usual course of action is to gradually remove parts of the program until you find a removal that changes the behavior. Then examine what you removed and look for problems. Watching variable locations in the debugger to see when they change is a useful tool.

Re: NaN - another why question?

bmchenry — Tue, 20 Oct 2009 19:01:36 GMT

You've answered your own question:
>At line 83 in READTEST.F there is a call to a GAPINI routine which checks the program licensing
>If I replace this call with GAPINI_FREE (no licence required) the ASSPAM read works correctly.
walk through with and without GAPINI. I am guessing something in GAPINI corrupts the memory storage location for the NaN variable.

Re: NaN - another why question?

jim_cox — Wed, 21 Oct 2009 20:00:51 GMT

Quoting - Steve Lionel (Intel)

I wanted a small test case that showed the problem. You have evidently discovered that you probably have a bug elsewhere in the program that is manifesting itself as the NaN. Perhaps you're accessing off the end of an array or have an argument mismatch, or something else. Your program is a mix of Fortran and C++ and may also be corrupting the stack with mismatched calling conventions.
...
The usual course of action is to gradually remove parts of the program until you find a removal that changes the behavior. Then examine what you removed and look for problems. Watching variable locations in the debugger to see when they change is a useful tool.

I would have hoped that argument mismatch and array bounds would be caught during compile or runtime. I'm not seeing any messages.

C and C++ are compiled with _stdcall, with iface CVF for the fortran, string length after each. The settings are the same as work on the current compiler.

Stack corruption etc is getting past the edge of my experience as a (mostly) applications porgrammer.

Its 'why wont this "known good" old code run?' questions for me usually. Trying to jump it across two generations of copmpilers is certainally proving to be an "interesting learning experience" :(

Looks like I'll need a 'Dummy's Guide to Intel Stack Debug"

How do I find the stack's base memory location and the size ?

Thankx for your help

Jim

=mjc=
.

Re: NaN - another why question?

jim_cox — Wed, 21 Oct 2009 20:35:03 GMT

Quoting - bmchenry

I'm not convinced that it is a corruption of the storage location of the ccpm array

Yes, I can see that LOC(ccpm) varies with the different compiles. 21479004 as against 21432988

In both cases the ccpm array is specifically intiialised to 0.00 by the code.

The array doesnt move, the correct array entry is set.

Apparently the read returns either the correct 24.91 or NaN depending on which code is included. The array is ciorrectly defined, and that same definition is used in both cases.

But you can be sure I willl be examining all the differences between the GAPINI routines very very carefully

Thankx for your input

Jim

Re: NaN - another why question?

jim_cox — Thu, 22 Oct 2009 00:38:28 GMT

Not sure if this is better or just weirder

Played with the differences between the gapini and gapini_free routines

Removed all unused variables, turned on fp stack checking, run timr warnings etc etc

Trying isolating sections of code

Found two library routines called GAPINI only

Both these routines USE IFPORT and have a CALL RANDOM(ARND) where ARND is a locally defined real*4

When I started playing with these - I started getting all sorts of 'odd' unhandled exceptions

And some "error #6284: There is no matching specific function for this generic function reference" compile messages

But if I change it to CALL RANDOM_NUMBER(ARND) it works - well at least as far as sorting the NaN problems I was seeing

Go figure....

Re: NaN - another why question?

jimdempseyatthecove — Thu, 22 Oct 2009 16:41:02 GMT

Restore the code to call RANDOM.
Place break point on call.
Open Memory Window to show ARND (and data that follows)
Then step over RANDOM

Does location(s) following the 4 bytes of ARND get changed?

This may indicate that a user supplied subroutine of the name RANDOM is being called as opposed to the runtime library named RANDOM.

The runtime library RANDOM does have SAVE variables for state. These may be interacting with your license check routine in an adverse way. (intended or unintended).

Jim Dempsey

Jim Dempsey

Re: NaN - another why question?

jim_cox — Thu, 22 Oct 2009 20:02:01 GMT

Quoting - jimdempseyatthecove

I fear thiers is a good chance chance that this may have been the case.

So I've gone through that area of code pretty hard - removed unused variables etc,. There were also a number of un-needed equivalences. There was also an instance of the editor finding a variable name to be a reserved word.

Compiling IMPLICIT NONE is almost certainally helping.

It caught the follwoiing ugly implicit declaration of BUFF1
CHARACTER*1 DUM(80),BUFF(80)
EQUIVALENCE (BUFF(1),BUFF1)
which was one of the few declaration differences between my two code peices

Wondering if the difference might have been a program vs library debug dll issue, and seeing the retun as underflow - maybe.

Where the symptomis are first seen can sure be miles away from the cause

And ow have code that now runs to completion.

So onwards to output testing :)

I wonder how stable it is?

And a Happy Friday to all :)

Jim

=mjc=
.

Re: NaN - another why question?

jimdempseyatthecove — Fri, 23 Oct 2009 04:23:50 GMT

Whoopieee!!!!

Jim D.

Re: NaN - another why question?

Steven_L_Intel1 — Fri, 23 Oct 2009 13:19:12 GMT

Quoting - jim.cox

There was also an instance of the editor finding a variable name to be a reserved word.

There are no reserved words in Fortran. It is perfectly OK to have a variable that is the same as a language keyword. In some cases it might be a bit confusing, but it is not an error.

Re: NaN - another why question?

jimdempseyatthecove — Fri, 23 Oct 2009 14:47:33 GMT

Quoting - Steve Lionel (Intel)

There are no reserved words in Fortran. It is perfectly OK to have a variable that is the same as a language keyword. In some cases it might be a bit confusing, but it is not an error.

??You mean I can redefine IF, GOTO, RETURN, SUBROUTINE, ...

SUBROUTINE FOO(IF)
INTEGER :: IF
IF = 12345
END SUBROUTINE FOO

Is that valid?

What about

SUBROUTINE FOO(IF)
INTEGER :: IF
IF(IF .eq. 0) IF = 12345
END SUBROUTINE FOO

Where context (may) disambiguate the syntax.

Jim