Showing results for 
Search instead for 
Did you mean: 
1 View

Cast INTEGER*2 array to INTEGER*4


The conversion of the Powerstation code to Intel Fortran is nearly finished.I got the compile time errors dealt with and now I am dealing with warnings.

I have a function, that takes an INTEGER*4 as argument and an INTEGER*2 array with an equal dimension.


    integer*4 function get(icommon,ivar,ilaenge,ityp,irefu,lh)
    !DEC$ATTRIBUTES Value :: icommon,ivar,ilaenge,ityp,irefu
    !DEC$ATTRIBUTES Reference :: lh
    integer*4 icommon,ivar,ilaenge,ityp,irefu
    integer*4 lh
    end function get
    End Interface

Calling Code:

        INTEGER*2 L2(1)
        COMMON /CRST
     1  / M01,M02,M03,M04,M05,M06,M07,M08,M09,M00,LH(1200)
        EQUIVALENCE (LH(101),L2)

          I = GET(320,JL,12,5,0,L2(JS))

Please don't judge the use of EQUIVALENCE and COMMON blocks. I can only fix one design flaw at a time and I'm still learning Fortran. L2 is used throughout the code to interpret the INTEGER*4 LH array as two byte INTEGER*2s. In C i would do some byte shifting to split the 4-byte integer in two.

However since GET expects an INTEGER*4 and L2(JS) is an INTEGER*2 the compiler warns me correctly, that the arguments datatype does not match the definition. Since such behavior does only work when the array is not segmented, I am looking into solutions, that either avoid the array conversion or make sure that the array is sequential and cast L2(JS) + L2(JS+1) to an INTEGER*4.

Thank you

0 Kudos
2 Replies
1 View

The blunt instrument approach

The blunt instrument approach is to add:


to the function. This will disable the argument type checking. Does the function operate correctly when passed the wrong type?

Retired 12/31/2016
0 Kudos
1 View

Thank you. When compiled with

Thank you. When compiled with Powerstation it does. I will know soon, if it is the same with the Intel Compiler. We are currently updating to the latest code base to have a side-by-side comparison.

0 Kudos