Code variation with change in PARAMETER

[NotThatItMatters]

I compiled a large executable with a current compiler (2013 SP1 Update 3-202) and noted a problem running a specific input set between code which had a single initialization routine with the line

[fortran]

      REAL (KIND = F), PARAMETER :: BBLPERCUFT = 96.0_F / 539.0_F

[/fortran]

and code with the line(s)

[fortran]

      REAL (KIND = F), PARAMETER :: BBLPERCUFT =
     &  1.0_F / (49.0_F / 12.0_F) / 1.375_F

[/fortran]

Because the updated code caused a crash, I then recompiled both with an older compiler (2013 SP1 Update 1-103).  I am noting the latter executable compiles with a size larger by 412 bytes.  By the way, it is the latter executable which "works".  So what is going on here?  What could possibly be the difference between the two executables?

[NotThatItMatters]

Sorry, the "older" compiler is 2013 SP1 Update 1-139.

[Steven_L_Intel1]

Those two PARAMETER statements are treated identically. What was the "crash"? You're saying that compiling with the older compiler resulted in larger code size? That's not too surprising.

[NotThatItMatters]

The same compiler was used with both A and B, and the executable sizes differed by 412 bytes.  The crash in the code compiled with A was not a crash per se, but rather a running of the code generating NaN whereas B does not generate NaN when run.  If I put the standard floating point test to catch NaN (fpe:0), both codes will not run because of numerous problems with underflow.

[Steven_L_Intel1]

I'd be interested in seeing the actual program in both versions. You can submit it through Intel Premier Support and ask that it be assigned to me. Please include everything needed to build and run the program.

[NotThatItMatters]

That is going to take a little doing.  I have done this in the past, and the sequence necessary to run the code is a bit convoluted.  You see, the Fortran exe is usually spawned from a VB6 process with use of the Shell command.  Let me make a valiant attempt to get this done.

[jimdempseyatthecove]

If the source file is of fixed format then it may be possible that the continuation line is improperly formatted in a way that obscures the error from compilation, yet induces the error at run time. An example of this would be if the "1" were removed from the 1.0_F/....

Often a cause of seeing an abundance of NaN's is when a program is expecting uninitialized variables to be initialized to 0.0.

If file is fixed form, then as a first measure, insert as a first line PRINT *,"BBLPERCUFT=", BBLPERCUFT.

As a second measure, compile with the diagnostics for use of uninitialized variables.

Jim Dempsey

[Steven_L_Intel1]

Jim has good ideas here. At a minimum you could provide the source where you are seeing the difference, in both forms, that I could compile. That would at least allow me to understand why you see a difference by rewriting the PARAMETER declaration.

[NotThatItMatters]

All the compilation options Jim mentions are utilized.  I have submitted the full set to premier support with ID #60000053967 with your name referenced, Steve.  I hope this helps.

[Steven_L_Intel1]

Thanks very much. You are absolutely right, the code does change, and in a way that is not trivial. This will take some digging.