Strange behaviour of Fortran DLL called by VB.NET

[Francesco_B_6]

Goodmorning,

I've created a Fortran dll with IVF under Windows 7 64bit. The only non-standard option used is "Calling Convention: CVF".

I've tested it with an executable created in IVF and it works fine.

However when I call it from a VB.NET program I get a strange behaviour: when there is an IF statement that contains an .AND. the code doesn't work.

For example: if there are two logical variables myVar1 = .TRUE. and myVar2 = .TRUE. , if I write the statement IF (myVar1 .EQ. .TRUE. .AND. myVar2 .EQ. .TRUE.) the code jump it, but only when I call the dll from VB.NET.

Can someone help me? Thank you in advance.

Francesco

[JVanB]

Your code is nonstandard and IVF puts the following interpretation on it: myVar1 .EQ. .TRUE. is the action of a binary arithmetic operator on two logical operands. In this case, IVF converts both the logical operands to integers (by some means unspecified in IVF docs; let's assume TRANSFER) and then carries out the operation, the result being default logical because that's the type of result of the intrinsic OPERATOR(.EQ.). Then it does the same thing to myVar2 .EQ. .TRUE. and then ANDs the results to get the result tested by the IF statement. Code compiled with the switch /fpscomp:logicals has a different internal representation of .TRUE. than code without, so this could cause myVar1 .EQ. .TRUE. to evaluate to .FALSE. even though myVar1 was set to .TRUE. somewhere in another file. You might try to track this down to see if IVF is doing this even though myVar1 was set to .TRUE. in the same file and if so file a bug report. You could make life easier for yourself by switching to the standard-conforming IF(myVar1 .AND. myVar2) syntax.

[Francesco_B_6]

Thank you for the answer, you are right it was a matter of non-standard syntax. I've also found a clarifying post on the argument: http://software.intel.com/en-us/forums/topic/274462 Thank to it, I was able to modify my code and now it works perfectly. I've replaced .EQ. operators to .EQV. for logicals and added parenthesis when there was a .AND. or .OR. Many thanks

[JVanB]

Two concerns: 1) I hope you didn't change myVar1 .EQ. .TRUE. to (myVar1 .EQV. .TRUE.), as this is one of my pet peaves. Looking at the truth table in terms of the values of myVar1, one can see that (myVar1 .EQV. .TRUE.) has the same value as myVar1. Similarly, (myVar1 .NEQV. .TRUE.) has the same value as .NOT. myVar1. So I can't stand to see anything .EQV./.NEQV. to .TRUE./.FALSE.. 2) It is not a matter of non-standard syntax. Even with your non-standard syntax, if everything were compiled with /fpscomp:nologicals or all with /fpscomp:logicals, your snippet would have worked out OK. It's mixing of the two switches that causes the failure. As an example, compile nologs.f90 with ifort /c /fpscomp:nologicals /stand:f95 nologs.f90 and then compile logs.f90 with ifort /fpscomp:logicals /stand:f95 logs.f90 nologs.obj. Incorrect result are obtained for this standard-conforming code. Any other combination of switches yields correct results.