Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26756 Discussions

Strange problem with assignment or conversion

Ibrahim_K_
New Contributor I
104 Views

Dear Friends:

In a small subroutine I have the following segment of code:

         RX3=ENORM(3)
         WRITE(6,5010)	FSTIFF,FRIC,DREF,(ENORM(I),I=1,3),NPS
         WRITE(6,5008)	ENORM(3)
         WRITE(6,5009)	RX3
 5008 FORMAT(E15.5)     
 5009 FORMAT(E15.5)
 5010 FORMAT(6F10.2,I5)

the output I get strangely is:

      2.00      1.00     11.00     -0.29      0.00      0.96    4
    0.95630E+00
    0.10646E+10

The only special thing here is (if at all) that ENORM(3) appears in a COMMON block and I am using classical implicit naming convention. I declared XR3 as REAL locally.

I must be doing something really silly! Any ideas?

I. Konuk

0 Kudos
6 Replies
Steve_Lionel
Black Belt Retired Employee
104 Views

Without seeing the rest of the code, it's pretty difficult to help. I usually find that snippets like this omit crucial information. My recommendation is to produce a cut-down version of the program that still reproduces the behavior. Usually, in the process, you'll discover what caused the problem. Come back here with a small but complete test case if you still need help.

Ibrahim_K_
New Contributor I
104 Views

Dear Steve:

Thank you again very much. 

The original problem popped up in large C++/FORTRAN mixed language program. In the last two hours or so I did several single language and mixed language mini code. I could not generate the problem.

However, I isolated or got around the problem in the original code. When I changed the name RX3 to MYRX3, the problem went away. I then reintroduced RX3 and assigned another variable to it. No problem. It seems like that one assignment ( RX3=ENORM(3) ) is causing some sort of problem. I could not locate where the value of RX3 come from.

Best regards;

I. Konuk

mecej4
Black Belt
104 Views

Does your program contain EQUIVALENCE declarations? 

Ibrahim_K_
New Contributor I
104 Views

mecej4 wrote:

Does your program contain EQUIVALENCE declarations? 

Not this program. Bu I have several declarations binding FORTRAN COMMON blocks to C++ structures like:

COMMON/SEAFND/FSTIFF,FRIC,DREF,XREF(3),ENORM(3),NPS
BIND(C,NAME='SEAFND') :: /SEAFND/

 

 

 

Ibrahim_K_
New Contributor I
104 Views

Steve Lionel (Ret.) (Blackbelt) wrote:

Without seeing the rest of the code, it's pretty difficult to help. I usually find that snippets like this omit crucial information. My recommendation is to produce a cut-down version of the program that still reproduces the behavior. Usually, in the process, you'll discover what caused the problem. Come back here with a small but complete test case if you still need help.

 

Steve was totally correct. I found the problem. It is my fault.

I was declaring the COMMON blocks in a MODULE which contained:

    ! ISO_C_BINDING module is required for C++ and FORTRAN interoperability
    use,intrinsic::ISO_C_BINDING

    ! standard Fortran IV convention
    !
    IMPLICIT INTEGER(C_INT) (I-N)
    IMPLICIT INTEGER(C_FLOAT) (A-H,O-Z)

When I included the IMPLICIT statements in the above form or simply in form:

      ! standard Fortran IV convention
      !
      IMPLICIT INTEGER (I-N)
      IMPLICIT INTEGER (A-H,O-Z)
      !

everything works OK. 

What was happening is that without the IMPLICIT statement the compiler seems to assume that ENORM(3) array is INTEGER type and converting it to real. When I assigned the content of ENORM(3) to MYRX3 instead of RX3 the problem seemed to go away. Perhaps Steve can explain why the compiler picks on ENORM? Is the convention I am using NOT the default - variable starting with E REAL?

Regards;

I. Konuk

Ibrahim_K_
New Contributor I
104 Views

Apologies to ALL. It is so silly. It took me three days to see the"INTEGER" in the second IMPLICIT STATEMENT. Everything now make sense!

Reply