Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28384 Discussions

Strange problem with assignment or conversion

Ibrahim_K_
New Contributor I
363 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
Honored Contributor III
364 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.

0 Kudos
Ibrahim_K_
New Contributor I
364 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

0 Kudos
mecej4
Honored Contributor III
364 Views

Does your program contain EQUIVALENCE declarations? 

0 Kudos
Ibrahim_K_
New Contributor I
364 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/

 

 

 

0 Kudos
Ibrahim_K_
New Contributor I
364 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

0 Kudos
Ibrahim_K_
New Contributor I
364 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!

0 Kudos
Reply