invalid floating point operation

invalid floating point operation

Hi all;

I am getting an invalid floating point operation error in release mode, which is not the case in the debug mode.I do not think thatthis is because of project setting differences between these two modes, since I already tried almost every combination.

The most interesting point is, I get the same error also in debug mode with "debug information format = line numbers only".
I get the error in the following line:

if (x .gt.0 .and. y .gt. 0) then
check=.not. ((REAL(t)/x .le. p/y).and.(REAL(t)/x .lt. 2))
else
check = .true.

However, unfortunately,I cannot see the current values of these variables since debug information format is
"line numbers only".

When I put a write statement in front of the lines above, the problem interestingly disappears.

What may be the problem ? Someting about compiler optimization or floating point stack ?

46 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - ylmz
if (x .gt.0 .and. y .gt. 0) then
check=.not. ((REAL(t)/x .le. p/y).and.(REAL(t)/x .lt. 2))
else
check = .true.

It does look like the compiler may be setting up to execute the division unconditionally. Did you set /fp:precise ?

Try making a logical function out of the if/then/else/endif block passing in x, y, p (use conditional compilation so you can easily switch back and forth).

If the problem goes away then the compiler optimization might be at fault. See if you can construct a simple test case and submit it to premier support.

Also try

if (x .gt.0 .and. y .gt. 0) then
tOVERx = REAL(t)/x
check=.not.(tOVERx .le. p/y).and.(tOVERx .lt. 2.0))
else
check = .true.

Note the 2.0

Also,what type are x, y, t and p?

Jim Dempsey

www.quickthreadprogramming.com

Quoting - tim18
It does look like the compiler may be setting up to execute the division unconditionally. Did you set /fp:precise ?

Hi Tim;

Now I tried what you said, but it says:

"ifort: command line error: use of '/fp:' option along with a floating point precision option not supported"

what should i do ?

Hi Jim;

x is INTEGER(2)
y is REAL(4)
t is INTEGER(2)
p is REAL(4)

Quoting - ylmz

"ifort: command line error: use of '/fp:' option along with a floating point precision option not supported"

what should i do ?

Please show us the command line you are using to compile.

Steve - Intel Developer Support

Quoting - Steve Lionel (Intel)
Please show us the command line you are using to compile.

The following command line is for Visual Fortran compiler:

/nologo /Oy- /Qparallel /assume:buffered_io /include:".Release2/" /DRELEASE_EXTERNAL /DNDEBUG /DDEBUG_CPU /DCOMPILER_IS_IVF /assume:nocc_omp /extend_source:132 /fpscomp:ioformat /fpscomp:logicals /warn:errors /stand:f90 /warn:declarations /warn:unused /warn:truncated_source /warn:interfaces /Qsave /align:commons /align:sequence /Qzero /fpe:0 /names:as_is /iface:cvf /module:".Release2ForLib/" /object:".Release2ForLib/" /traceback /check:format /check:output_conversion /libs:dll /threads /c

and the following is for C++:

/Ob2 /Oi /Ot /Oy /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "FATES2000" /D "_VC80_UPGRADE=0x0710" /D "_AFXDLL" /D "_MBCS" /GF /FD /EHsc /MD /Zp4 /Gy /Yu"stdafx.h" /Fp"Release2Fates.pch" /Fo"Release2" /Fd"Release2vc90.pdb" /W4 /nologo /c /Wp64 /TP /wd4290 /errorReport:prompt

By the way, I do not believe that there are any unexpected numbers such as (0 / 0) in the lines of code that I gave before.

I forgot to say that I'm making calls from a C++ project to a fortran function through a .lib file in MS Visual Studio 2008 environment. I'm using Intel's Visual Fortran compiler.

We very recently hit a similar problem, though I wouldn't expect it to happen without at least some optimization turned on. Is the code shown inside a loop?

There is a mismatch between the C++ and FORTRAN expectations as to whether or not FP exceptions are enabled. It gets worse when you are writing FORTRAN libraries than can be called with either setting. We used the "safe" setting for fp speculation to get around it.

The code in our case was a tight loop doing conditional assignment with an explicit division in the RHS, conditional on the divisor being not-too-close-to-zero. This was being compiled as an SSE2 vector sequence using and/or masking logic to overwrite the result of the division with the "else" case value (a simple array lookup) in the register before writing the result back to the array. Nice pretty branch-free vector code but not semantically equivalent to the source when FP exceptions are enabled.

That's probably what you're seeing but why it's dependent on the type of DB info generated is puzzling. Perhaps the setting to choose that DB format is equivalen to no debugging in terms of the resultant optimizer settings?

Quoting - ylmz

The following command line is for Visual Fortran compiler:

/nologo /Oy- /Qparallel /assume:buffered_io /include:".Release2/" /DRELEASE_EXTERNAL /DNDEBUG /DDEBUG_CPU /DCOMPILER_IS_IVF /assume:nocc_omp /extend_source:132 /fpscomp:ioformat /fpscomp:logicals /warn:errors /stand:f90 /warn:declarations /warn:unused /warn:truncated_source /warn:interfaces /Qsave /align:commons /align:sequence /Qzero /fpe:0 /names:as_is /iface:cvf /module:".Release2ForLib/" /object:".Release2ForLib/" /traceback /check:format /check:output_conversion /libs:dll /threads /c

Wow - that's a lot of options for Fortran. Do you know what all of them do?

Unless you know you have a need for these, reset to the defaults these: /fpe:0, /Qsave, /Qzero, /fpscomp:ioformat, /fpscomp:logicals, /iface:cvf

I VERY strongly recommend against using /names:as_is. That has no bearing on the problem at hand, but why is it there?

What does your declaration of the Fortran routine on the C++ side look like? I'm going to guess that you're corrupting the stack because of a C-STDCALL mismatch. Removing /iface:cvf could be a test of that.

Steve - Intel Developer Support

The IEEE_HANDLER can catch an Invalid Operation if the IEEE_FLAG has been set. Shouldn't Traceback kick in and identify the module and other gory details in which the exception is flagged?, it not always being where you think is.

Gerry

Quoting - ylmz
Hi Jim;

x is INTEGER(2)
y is REAL(4)
t is INTEGER(2)
p is REAL(4)

You might find this faster:

check = .true. 
if (x .gt. 0 .and. y .gt. 0.0_4) then
   if(t/x .lt. 2) then
     check =((REAL(t)/REAL(x) .gt. p/y)
   endif
endif

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

Jim

www.quickthreadprogramming.com

Oops I ment

check = .true. 
if (x .gt. 0) then
   if(y .gt. 0.0_4) then
     if(t/x .lt. 2) then
       check =((REAL(t)/REAL(x) .gt. p/y)
     endif
   endif
endif

Fortran evaluates all terms of the (expr .and. expr) as opposed to C/C++ breaking out in the middle of the evaluation.

The above code reduces the number of tests and conversions from integer to real

Jim

www.quickthreadprogramming.com

Steve;

Yes, indeed this line is executed inside a large loop. But what is the effect of a loop in this situation ?

Hi Steve;

The function declaration is as follows:

bool __stdcall fortranCall(long *p_res);

Gerry;

Actually wedisabled the associated exception bit in the control register and
traced the problem ourselves by checking the status register after almost
every block. We detected the problemat the same place. But the most interesting pointis,
when we put an additional line of code just above to the line where we are getting the error,
the problem disappears.
( this additional line may be even completely irrelevant,
for example: write (1, *) 'zzz' )

Quoting - ylmz
Gerry;

Actually wedisabled the associated exception bit in the control register and
traced the problem ourselves by checking the status register after almost
every block. We detected the problemat the same place. But the most interesting pointis,
when we put an additional line of code just above to the line where we are getting the error,
the problem disappears.
( this additional line may be even completely irrelevant,
for example: write (1, *) 'zzz' )

That sounds a lot like stack or memory corruption to me.

Hi Jim;

I tried what you proposed. But still I'm getting the error. I guess the error is not specific to this line, because the numbers at that point are even not close to zero. Can it be something related to floating point stack, etc. ?

Quoting - gib

That sounds a lot like stack or memory corruption to me.

Gib,

Yes, that is why we rarely get it in the debug mode, I guess.

I changed some compiler options, and now I geta completely differenterror:

"access violationREADING location 0x..." (and sometimes, "access violation WRITING location 0x...")

Here is the line where it occurs:

stddev_x = MAX(stddev_y, SQRT(stddev_x / MAX(icount, 1_2)))

Now in the code on this line, there is neither an explicit read nor write ata specific memory location.

Doesthe problem occurmaybe because parameters to functions SQRT and MAX cannot be passed correctly ?
Corrupted stack etc. ?

In this context "read" and "write" mean get data from memory and put data into memory.

This kind of error is often associated with exceeding an array bounds, and/or uninitialised variables.
For a start I would suggest you look at Project->Properties->Fortran-> Run time-> Run time Error Checkingand turn on the checks for array and string bounds, and uninitialised variables.
If this does not throw up any problems then you may be reduced to printing out values at various stages of the program. Howeveradding write statements to code often has the effect of moving these "access violation"problems to somewhere else :-( This is known as a Heisenbug.

Les

Quoting - ylmz

Hi Steve;

The function declaration is as follows:

bool __stdcall fortranCall(long *p_res);

Then if the other values within the function remain constant for the duration of the application the only variable is the pointer to p. What is the value of the pointer to p at the time of error? (not the value pointed to by p)

p is likely pointing into La La Land

Also, I believe you want extern "C" for calling convention (caller cleans up stack) as opposed to __stdcall.
If the Fortran subroutine is not using the same calling convention it will be likely that you have corrupted the stack.
e.g.
float A, B, C;
...
retA = fortranCall(&A); // calling convention screws-up stack pointer
retB = fortranCall(&B); // *** not passing address of B ***
//(and calling convention screws-up stack pointer again)
C = A + B; // not using A, B, C

And be careful about the return value. C/C++ bool true is 1, Fortran LOGICAL .TRUE. = -1.

Upon return of "true" if your subsequent code uses

if(retValue) // will work
if(retValue == true) // will not work as intended

Jim Dempsey

www.quickthreadprogramming.com

Yes, we declare it as extern "C".

By the way, I do not know what does COMPILER_IS_IVF preprocessor definition mean. Could it be leading the problem ?

Quoting - ylmz
Yes, we declare it as extern "C".

By the way, I do not know what does COMPILER_IS_IVF preprocessor definition mean. Could it be leading the problem ?

I guess it is Intel Visual Fortran :)

Quoting - Les Neilson
For a start I would suggest you look at Project->Properties->Fortran-> Run time-> Run time Error Checkingand turn on the checks for array and string bounds, and uninitialised variables.

I tried this with "check all" option. The following is the only warning that I get:

[fortl: warning(402): fort:(1): In call to I/O routine, an array temporary was created for argument #1.]

I guessthis has a drawback only in terms of performance. Or would it bethe reason forthis error ?

The array temporary message is just a performance warning.

I suggest adding the option Fortran > Floating Point > Check Floating Point Stack > Yes.

If you get an access violation when running with this on, this will indicate that the floating point stack has become corrupted.

I also notice that the option "Generate Interface Blocks is NOT enabled. You should turn that on and rebuild.

It would really help if we could see a complete test case.

Steve - Intel Developer Support

Quoting - ylmz
Yes, we declare it as extern "C".

By the way, I do not know what does COMPILER_IS_IVF preprocessor definition mean. Could it be leading the problem ?

In an earlier post you stated
>>
The function declaration is as follows:

bool __stdcall fortranCall(long *p_res);
<<

which is not an extern "C" declaration in your C++ function prototype.

To verify, place the following in theC++ code where you firstissuefortranCall(...

intptr_t here; // here is a local stack variable
here = (intptr_t)&here; // place address of here into here
fortranCall(YourArgumentHere);
if((intptr_t)&here != here) // verify stack pointer not bunged up
{
printf("Calling convention errorn");
exit(-1);
}

www.quickthreadprogramming.com

Quoting - jimdempseyatthecove

In an earlier post you stated
>>
The function declaration is as follows:

bool __stdcall fortranCall(long *p_res);
<<

which is not an extern "C" declaration in your C++ function prototype.

To verify, place the following in theC++ code where you firstissuefortranCall(...

intptr_t here; // here is a local stack variable
here = (intptr_t)&here; // place address of here into here
fortranCall(YourArgumentHere);
if((intptr_t)&here != here) // verify stack pointer not bunged up
{
printf("Calling convention errorn");
exit(-1);
}

Hi;

Actually I did not write the prototype exactly, but it was declared inside a block as follows:

extern "C"
{
...
bool __stdcall fortranCall(long *p_res);
...
}

And I tried what you said, but I did not get an unusual result.
Actually I could not exactly understand the point in doing this.
"here" is a variable, and its address is pointing to a constant memory
location.Is it subject to change with stack pops and pushes ?

Quoting - Steve Lionel (Intel)
The array temporary message is just a performance warning.

I suggest adding the option Fortran > Floating Point > Check Floating Point Stack > Yes.

If you get an access violation when running with this on, this will indicate that the floating point stack has become corrupted.

I also notice that the option "Generate Interface Blocks is NOT enabled. You should turn that on and rebuild.

It would really help if we could see a complete test case.

Actually I am trying to preapare a test case, but it is really difficult to catch the error when I do not use all the project files as a whole.

I added the "check floating point stack" option and ran again, however I did not receive any errors. Does this mean we can be sure that the problem is not originating from floating point stack corruption ?

When I enable "Generate Interface Blocks" option, I really get a lot of compilation errors stating that actual argument and expected parameter types do not match. Some of these violations are

REAL(4) --> REAL(8)
REAL(8) --> REAL(4)
INTEGER(2) --> INTEGER(4)
INTEGER(4) --> INTEGER(2)

As far as I know, the compiler will handle the situations where a smaller size is assigned to a larger sizevariable. Is this also the case in the opposite direction ? If not, the compiler is pushing the passed parameters asis ? If so,
why do not we getting an error when "Check Floating Point Stack"option is on ?

Those errors are the cause of your problem. Yes, in an assignment statement conversion is done but not for argument association. You are corrupting memory and/or referencing garbage data. Fix the errors detected by Generate Interface Blocks and the other errors will likely go away.

Steve - Intel Developer Support

Quoting - ylmz

Hi;

Actually I did not write the prototype exactly, but it was declared inside a block as follows:

extern "C"
{
...
bool __stdcall fortranCall(long *p_res);
...
}

And I tried what you said, but I did not get an unusual result.
Actually I could not exactly understand the point in doing this.
"here" is a variable, and its address is pointing to a constant memory
location.Is it subject to change with stack pops and pushes ?

The stack local variable "here", for the duration of any individual call, is supposed to remain constant.
The suggested test code was to assert that the location of the variable did not change through the function call.
The suggested test code also has the side effect of verifying if the value contained in "here" prior to the call (was address of variable "here") is not corrupted by the call (called routine stomped on it).

The things than can cause this apparently impossible circumstance are:

The calling convention between C++ and Fortran are not the same and therefor the stack pointer (ESP) is not properly restored.

The calling convention between C++ and Fortran are not the same andsave/restore stack frame pointer (EBP) is not consistantly used andis not properly restored.

(rare) The calling convention is messed up such that the C++ this pointer gets hosed.

The calling convention is messed up where you call the fortran routine with the address of an array of data, however the fortran routine is expecting the address of an array descriptor.

In some cases the address of "here" changes, in other cases you stomp on memory you ought not be stomping onto.

Jim

www.quickthreadprogramming.com

Hi;

I enabled the "generate interface blocks" option. However,itbehaves nondeterministically.
That is, when I try to compile, I get some errors not received in one of the previous builds,
although the codes were exactly the same. What could be the reason ?

(i mean only the errors like "formal parameter and argument type mismatch")

This feature is dependent on the order of compilation. If you are calling a routine in a different file, it can't check the interface unless the other file was compiled first.

Steve - Intel Developer Support

Hi;

I solved all issues related with "generate interface blocks". However, I still get the same error (invalid floating point operation)

In most of the cases, I solved the issues in the following manner:

Assume that subroutine S expects a REAL(4) as a parameter. And S used to be called with a REAL(2).
I changed thecalls as S(REAL(parameter, 4)) That is, I applied explicit type casting. Buthow the dynamics
of fortran act here?A new dummy address is created, or subroutine S is informed that it will be able to use the address of "parameter" as if it holds 4 bytes, not 2 ?

And what about the situations like Q(19) ==> Q(INT(19, 2)) ? I mean, whatthe situation will be in case of constant arguments ?

There is no REAL(2) in our implementation - just 4, 8 and 16.

The answer to your question is that if you pass an expression such as INT(19,2) then the compiler makes a temporary value and passes that to the routine. The routine can store into the value, but any changes are lost when the routine returns.

You can change the kind of literal constants by adding a kind specifier like this: 19_2. This means the number 19 of kind INTEGER(2). You can do this with reals as well - 4.5_8 means 4.5 as REAL(8). Better practice is to declare some PARAMETER constants for the kinds you want to use and then use those constants. For example:

integer, parameter :: SP = SELECTED_REAL_KIND(6)
integer, parameter :: DP = SELECTED_REAL_KIND(15)
integer, parameter :: SINT = SELECTED_INT_KIND(4)
integer, parameter :: LINT = SELECTED_INT_KIND(9)
integer(LINT) :: A ! INTEGER(4)
real(DP) :: B ! REAL(8)
call sub(3.14_DP, 4_SINT) ! REAL(8), INTEGER(2)

At this point you may want to change the property Floating Point > Floating Point Exception Handling > /fpe:0 and see if you get a different error.

Steve - Intel Developer Support

>> And S used to be called with a REAL(2).

Simply changing the argument to REAL(2) for both caller and callee may or may not fix the problem. An example where this will not fix the problem is if you are reading a binary data file created with insturmentation that is using a 16-bit floating point formatted number (one of several formats). And there may be other reasons. To correct for this you will need to create function wrappers that handle this format. To do this you would a user defined type to express the REAL(2), the type name may have to be something like "SHORT_REAL".

Jim

www.quickthreadprogramming.com

Going back to your very first post, why don't you test

((y*REAL(t) .le. x*p) .and.(REAL(t) .lt. 2*x))

and avoid possible divide by zero?

Anthony,

Although your suggestion is good, the users code as written should have run without error, however it is erroring out. This error is symptomatic of a problem elsewhere in his code. Should your code suggestion eliminate the symptom, it will hide the fact that there is something seriously wrong elsewhere. It would be wise for this user to code with the error symptom and track down what is causing the error. Once found, he can than come back and insert the non-division test as you suggest.

There is nothing worse than a hidden error in a program. Especially if the error floats arround. When you have a consistant test case that exposes the error - use it now to find and fix the error. If the error does expose a compiler problem, then the error case needs to be reported back to the developers.

One of the oddest errors I had, and one of the hardest to track down, was not a programming error, nor a compiler code generation error. Instead, there was a Visual Studio WinDbg internal problem where it inserted a break point INT03 into (over the top of) code where a break point was not registered. What made this difficult to track down was this INT03 was not inserted over an instruction (a break would have occured), but it was placed over the tail end of the bytes of the instruction. This changed the instruction to reference other data than it was intended to reference. What made this particularly hard to track down was, whenever the debugger was in control, such as at break point or after GP fault, the INT03 was un-patched from the code (no evidence of coding problem). Also, when I edited the code, the INT03 got patched to the same address but was a different position in the code (when edit was to code that preceeded the problem location). Once I structured a test to verify the (almost undetectible) corruption of code, I could see the culpret was and INT03 (hex CC) being poked into and out of the code, this pointed the finger at WinDbg. A quick remove all break points, save project, exit, restart VS, and ta-da problem went away.

Jim

www.quickthreadprogramming.com

Hi all;

Yes,me toodo not think that this invalid floating point operation errorresults from a computational expression.
Its place differs according to different situations.

What I tried lastly was as follows:

I have a subroutine in fortran that checks the current status of the floating status register.It reports invalid operations by writing it into a text file. After every detection, it clears the status register.

subroutine floating_status_check (callNo, lineNo)

use IFPORT
include 'params.cmn'

integer(4) callNo, lineNo
integer(2) status

call GETSTATUSFPQQ(status)

! check for invalid result
if (IAND(status, FPSW$INVALID) .NE. 0) then
write (nfchkstat,*) callNo, lineNo
call CLEARSTATUSFPQQ()
end if

end subroutine floating_status_check

My main fortran function, which is called in a loop from C++ code is as follows:
(I place floating_status_check after every line of code in this function)

logical(1) function fortranCall(rsp_ptr)

...
integer(4) callNo
data callNo /0/
...

callNo = callNo + 1

call floating_status_check (callNo, 1)
...
call floating_status_check (callNo, 2)
...
...
...
call floating_status_check (callNo, 300)

end

Finally, when I check my output file, I get the following result:

7 1
19 1

Meaning, the error occured at 7th and 9th calls to the main fortran function, just at the beginning (line 1)
indicating that the error actually were there before this call.

However, if I put an additional floating_status_check just before the line "callNo = callNo + 1" with lineNo = 0
(call floating_status_check (callNo, 0)), then I get the following result:

6 0
18 0

That is, the error occures one iteration earlier.

Do you have any comments on this situation ?

What I can see is that, there is actually no invalid floating point operation occuring in the fortran part.
There is something wrong that comes from the C++ part, where no computational expressions exist.

1) Can it be a stack issue ? If yes, why I do not get any errors although all compiler options related to stack
anomalies are enabled ?

2) Also, despite this error (invalid operation), all the results stillseem to be meaningful. If it is corrupting the memory at some point, why strange results do not appear after that point ?

3) Can this be a problem related to struct alignment differences between fortran and c++ compiler ?

4) Can the problem be related to fortran string parameter passing ? That is, it allows us to omit the string length.
However, in our code there are some calls to functions which requires additional integer values beyond the string and its length. In this case if we omit the string length, how does the compiler distinguish among the string length parameter and justthe nextinteger parameter ?

Thank you all very much again for your patience :)

Quoting - ylmz
Hi all;

I am getting an invalid floating point operation error in release mode, which is not the case in the debug mode.I do not think thatthis is because of project setting differences between these two modes, since I already tried almost every combination.

The most interesting point is, I get the same error also in debug mode with "debug information format = line numbers only".
I get the error in the following line:

if (x .gt.0 .and. y .gt. 0) then
check=.not. ((REAL(t)/x .le. p/y).and.(REAL(t)/x .lt. 2))
else
check = .true.

However, unfortunately,I cannot see the current values of these variables since debug information format is
"line numbers only".

When I put a write statement in front of the lines above, the problem interestingly disappears.

What may be the problem ? Someting about compiler optimization or floating point stack ?

FWIT, this doesn't raise an invalid floating point operation for me in VS2008 whatever the configuration. Which version of VS are you using? If it's 2003 get rid of it.

I haven't followed this discursive thread in its entirety but in your latest post you indicate that the problem appears to be in the C client. Have you implemented an exception handler on the C side and walked the stack to determine where in the C code the invalid floating point operation occurs? If, as you say, no fp is going on in C then have your handler mask invalid fp's and see if it still crashes.

Gerry

I hope you got rid of REAL(2). Note that, as Steve said, there is no REAL(2) in Intel Fortran.

Quoting - gib
I hope you got rid of REAL(2). Note that, as Steve said, there is no REAL(2) in Intel Fortran.

Hi;

Yes, actually there were no REAL(2) usage in our code. I was just trying to make a quick type cast example in my question, and I mistakenly wrote REAL(2) :)

Actually it has been 2 weeks we have been dealing with this problem, but today we realized that it has nothing to do with the Fortran part. We just detected an uninitialized float array at C++ part, and when we initialize it there does not seem to be any problems any more, at least for now :)

We were getting this problem since that memory location allocated for the array holded garbage values (therefore garbage real value such as -1.#NAN etc.). And it is of course quite normal concidentially not to get it in debug version (I guess that location shifts to another region in memory im debug version, and by chance with some valid real values in it)

Again thanks to you all very much for your invaluable comments and suggestions...

Hi;

Actually the C++ was containing one invalid floating point operation, and it is solved.
However, we still get it at the Fortran part on the line that I wrote in one of my previous posts.
Anyway, I converted the calculation into pieces, and I get the error at the following line:

xInverse = 1.0 / x

( x being integer(2) and xInverse being real(4) )

Since I need to use xInverse, I tried to change the expression above as follows:

xInverse = x**-1.0

And I get no error with this change.

In another case (with different input), I get the same invalid operation error at the following line:

temp1 = js * temp2
( js being integer(2) and [temp1, temp2] being real(4) )

However, when I change the expression as follows, the error disappears:

temp1 = temp2 * js (only the order of temp2 and js are changed)

How can it be ? Actually in the first case maybe we are changing the alignment of the executable and associated memory (for variables, arrays etc.) by using the exponentiation operator. But can the memory alignment also
be changed in the second case ? (just the same line but only the order of multiplied values is changed)

If it is not a corrupted memory issue, then what can be the reason ?

Thanks again...

The way your errors change when you make code changes is typical with a Heisenbug (one which moves when you look at it). It is virtually certain that you have some sort of memory violation error, or stack corruption, in my opinion. Another tricky bug occurs when you pass a constant as a parameter (e.g. 1.0) to a procedure that modifies that parameter value. Do you have all run-time error checking turned on?

Change

xInverse = 1.0 / x

to

if(x .eq. 0) Call BugCheck()
xInverse = 1.0_4 / FLOATI(x)

See what happens

Jim Dempsey

www.quickthreadprogramming.com

Quoting - gib
The way your errors change when you make code changes is typical with a Heisenbug (one which moves when you look at it). It is virtually certain that you have some sort of memory violation error, or stack corruption, in my opinion. Another tricky bug occurs when you pass a constant as a parameter (e.g. 1.0) to a procedure that modifies that parameter value. Do you have all run-time error checking turned on?

Yes, all run-time error checking options are enabled.

So if this is the case, why we do not receive a stack error, or an array index or memory violation error ?
And all outputs seem quite meaningful, and just the same results when we get the error and when we do not get it.

Leave a Comment

Please sign in to add a comment. Not a member? Join today