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

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

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?

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.

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

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

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

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

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

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

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.

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);
}

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.

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

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.

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.

>> 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

((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

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.

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