• Trying to run datcom using gfortran but encountering errors

    From Ash@21:1/5 to All on Sat Oct 23 05:44:43 2021
    I'm trying to execute the datcom source code using MinGW gfortran on Windows.

    I followed the procedure of trying to compile the source code using the command:

    gfortran datcom.f -o datcom.exe
    where datcom.f contains the source code.

    but i'm getting a lot of errors during compilation. I have attached a snippet of a small part of the errors that were obtained during compilation if it helps. I'm pretty new to gfortran, so do understand if I've misread or missed something.

    Given below are few of the compilation errors obtained, along with the relevant bits of the source file:

    Error 1

    Error: Rank mismatch in argument ‘mess’ at (1) (rank-1 and scalar) datcom.f:9165:21:

    9165 | & 4HRE ,1,ROUTID)

    datcom.f lines 9164-9165 and relevant variable declarations:

    SUBROUTINE EQSPCE(X,R,P,S,NP,XE,RE,PE,SE,NE,DSEDX)
    !
    !*** TRANSFORMS 4-DIMENSIONAL ARRAY SO THAT THE 3 INDEPENDENT ARRAYS
    ! ARE EQUALLY SPACED
    !
    DIMENSION ROUTID(2)
    DIMENSION CR(6),CP(6),CS(6)
    DIMENSION X(1),R(1),P(1),S(1),XE(1),RE(1),PE(1),SE(1), &
    & DSEDX(20)
    DIMENSION VAR(4),LGH(4)
    DATA ROUTID/4HEQSP,4HCE /
    CALL INTERX(1,X,VAR,LGH,R,RE(I),NP,NP,0,0,0,0,0,0,0,0, &
    & 4HRE ,1,ROUTID)

    interx procedure interface:

    SUBROUTINE INTERX (NIND,TABLE,VAR,LENGTH,DEP,ANS,LIND,LDEP, &
    & LX1L,LX2L,LX3L,LX4L,LX1U,LX2U,LX3U,LX4U,MESS,NMSS,ROUT)
    DIMENSION MSSCL(21),RMSCL(21)
    DIMENSION LENGTH(4),TABLE(LIND,4),DEP(LDEP),VAR(4),ROUT(2), &
    & MESS(20)
    EQUIVALENCE(MSSCL(1),RMSCL(1))
    DATA MSSCL /4HINTE,4HRX ,19*0/
    DATA SRPMSS /4H1TIN/,HOL1/4H1EXP/


    Error 2

    Error: Type mismatch in argument ‘x2’ at (1); passed LOGICAL(4) to REAL(4) datcom.f:1245:72:

    1245 | & DATA(5),DATA(6),DATA(7),DATA(8),DATA(9),P,Q,R,S,T,NN,NM)


    Error 3

    Error: Actual argument contains too few elements for dummy argument ‘kol’ (1/80) at (1)
    datcom.f:40352:36:

    40352 | IF(LDM(I) .GT. 0) CALL RVALUE(KOL,L,NDML,NF,BLANK, &
    | 1

    More information about datcom can be found in the links below.

    What is Datcom?: https://www.pdas.com/datcom.html

    How to download and compile the source code: https://www.pdas.com/datcomdownload.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to ashish...@gmail.com on Sat Oct 23 21:05:15 2021
    On Saturday, October 23, 2021 at 5:44:45 AM UTC-7, ashish...@gmail.com wrote:
    I'm trying to execute the datcom source code using MinGW gfortran on Windows.

    I followed the procedure of trying to compile the source code using the command:

    gfortran datcom.f -o datcom.exe
    where datcom.f contains the source code.

    The sample shown uses free-form continuation line methods.

    gfortran, and many others, assume fixed form for names ending in .f.

    Try changing the ending to .f90 and recompile.

    Otherwise, you need to show more, and especially which columns things are in.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nick Denissen@21:1/5 to All on Sun Oct 24 05:12:12 2021
    On Saturday, October 23, 2021 at 10:05:17 PM UTC-6, gah4 wrote:
    On Saturday, October 23, 2021 at 5:44:45 AM UTC-7, ashish...@gmail.com wrote:
    I'm trying to execute the datcom source code using MinGW gfortran on Windows.

    I followed the procedure of trying to compile the source code using the command:

    gfortran datcom.f -o datcom.exe
    where datcom.f contains the source code.
    The sample shown uses free-form continuation line methods.

    gfortran, and many others, assume fixed form for names ending in .f.

    Try changing the ending to .f90 and recompile.

    Otherwise, you need to show more, and especially which columns things are in.

    I don't think the lines are the problem -- gfortran 10 made argument mismatches fatal. It builds for me on gfortran 11.2 with:
    gfortran -std=legacy datcom.f

    From the docs:
    -std=std
    Specify the standard to which the program is expected to conform, which may be one of ‘f95’, ‘f2003’, ‘f2008’, ‘f2018’, ‘gnu’, or ‘legacy’. The default value for std is ‘gnu’, which specifies a superset of the latest Fortran
    standard that includes all of the extensions supported by GNU Fortran, although warnings will be given for obsolete extensions not recommended for use in new code. The ‘legacy’ value is equivalent but without the warnings for obsolete extensions, and
    may be useful for old non-standard programs. The ‘f95’, ‘f2003’, ‘f2008’, and ‘f2018’ values specify strict conformance to the Fortran 95, Fortran 2003, Fortran 2008 and Fortran 2018 standards, respectively; errors are given for all
    extensions beyond the relevant language standard, and warnings are given for the Fortran 77 features that are permitted but obsolescent in later standards. The deprecated option ‘-std=f2008ts’ acts as an alias for ‘-std=f2018’. It is only present
    for backwards compatibility with earlier gfortran versions and should not be used any more.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to ashish...@gmail.com on Sun Oct 24 06:12:09 2021
    On Saturday, October 23, 2021 at 5:44:45 AM UTC-7, ashish...@gmail.com wrote:
    I'm trying to execute the datcom source code using MinGW gfortran on Windows.

    I followed the procedure of trying to compile the source code using the command:

    gfortran datcom.f -o datcom.exe
    where datcom.f contains the source code.

    Did you download the zip file from github, and unzip it?

    You should then be able to:

    gfortran -c *.f
    rm dtplot.o
    gfortran -o datcom.exe *.o

    But the first lines of interx.f should look like:

    SUBROUTINE INTERX (NIND,TABLE,VAR,LENGTH,DEP,ANS,LIND,LDEP,
    1 LX1L,LX2L,LX3L,LX4L,LX1U,LX2U,LX3U,LX4U,MESS,NMSS,ROUT)
    C
    C
    C THE PURPOSE OF THIS SUBROUTINE IS TO PERFORM A LINEAR INTERPOLATION
    C FOR UP TO FOUR INDEPENDENT VARIABLES. A TABLE LOOK-UP IS PERFORMED
    C PRIOR TO THE INTERPOLATION IN ORDER TO FIND THE TABLE VALUES BOUNDING
    C EACH OF THE INDEPENDENT VARIABLES.


    but yours look different.

    Note that SUBROUTINE starts in column 7, and the next line has a 1 in column 6.

    You have a strangely modified version, that seems to be wrong.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Ash on Sun Oct 24 12:35:18 2021
    Ash <ashishfb3099@gmail.com> schrieb:
    I'm trying to execute the datcom source code using MinGW gfortran on Windows.

    I followed the procedure of trying to compile the source code using the command:

    gfortran datcom.f -o datcom.exe
    where datcom.f contains the source code.

    but i'm getting a lot of errors during compilation. I have attached a snippet of a small part of the errors that were obtained during compilation if it helps. I'm pretty new to gfortran, so do understand if I've misread or missed something.

    Given below are few of the compilation errors obtained, along with the relevant bits of the source file:

    Error 1

    Error: Rank mismatch in argument ‘mess’ at (1) (rank-1 and scalar) datcom.f:9165:21:

    9165 | & 4HRE ,1,ROUTID)

    As the compiler says: There is an interface mismatch, MESS is an
    array of rank 1, and you are passing a scalar to it.


    datcom.f lines 9164-9165 and relevant variable declarations:

    SUBROUTINE EQSPCE(X,R,P,S,NP,XE,RE,PE,SE,NE,DSEDX)
    !
    !*** TRANSFORMS 4-DIMENSIONAL ARRAY SO THAT THE 3 INDEPENDENT ARRAYS
    ! ARE EQUALLY SPACED
    !
    DIMENSION ROUTID(2)
    DIMENSION CR(6),CP(6),CS(6)
    DIMENSION X(1),R(1),P(1),S(1),XE(1),RE(1),PE(1),SE(1), &
    & DSEDX(20)
    DIMENSION VAR(4),LGH(4)
    DATA ROUTID/4HEQSP,4HCE /
    CALL INTERX(1,X,VAR,LGH,R,RE(I),NP,NP,0,0,0,0,0,0,0,0, &
    & 4HRE ,1,ROUTID)

    interx procedure interface:

    SUBROUTINE INTERX (NIND,TABLE,VAR,LENGTH,DEP,ANS,LIND,LDEP, &
    & LX1L,LX2L,LX3L,LX4L,LX1U,LX2U,LX3U,LX4U,MESS,NMSS,ROUT)
    DIMENSION MSSCL(21),RMSCL(21)
    DIMENSION LENGTH(4),TABLE(LIND,4),DEP(LDEP),VAR(4),ROUT(2), &
    & MESS(20)
    EQUIVALENCE(MSSCL(1),RMSCL(1))
    DATA MSSCL /4HINTE,4HRX ,19*0/
    DATA SRPMSS /4H1TIN/,HOL1/4H1EXP/


    Error 2

    Error: Type mismatch in argument ‘x2’ at (1); passed LOGICAL(4) to REAL(4)
    datcom.f:1245:72:

    1245 | & DATA(5),DATA(6),DATA(7),DATA(8),DATA(9),P,Q,R,S,T,NN,NM)

    That is more serious. You are passing a LOGICAL to a REAL.
    The bit pattern of a LOGICAL is very likely to make absolutely no
    sense when interpreted as a REAL, this is probably a miscount in
    the argument list.


    Error 3

    Error: Actual argument contains too few elements for dummy argument ‘kol’ (1/80) at (1)
    datcom.f:40352:36:

    40352 | IF(LDM(I) .GT. 0) CALL RVALUE(KOL,L,NDML,NF,BLANK, &

    That might be a misdeclaration of KOL, or a very old style where
    a dimension of 1 was used as a shorthand for (*).

    | 1

    More information about datcom can be found in the links below.

    What is Datcom?: https://www.pdas.com/datcom.html

    I would probably contact the maintainer about these errors, the second
    one especially looks to be potentiall serious.

    You can use -fallow-argument-mismatch to downgrade these errors to
    warnings, but I would not recommend it on general principles.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cyrmag@21:1/5 to Ash on Sun Oct 24 09:51:44 2021
    On 10/23/2021 7:44 AM, Ash wrote:
    I'm trying to execute the datcom source code using MinGW gfortran on Windows.

    I followed the procedure of trying to compile the source code using the command:

    gfortran datcom.f -o datcom.exe
    where datcom.f contains the source code.

    but i'm getting a lot of errors during compilation. I have attached a snippet of a small part of the errors that were obtained during compilation if it helps. I'm pretty new to gfortran, so do understand if I've misread or missed something.

    Given below are few of the compilation errors obtained, along with the relevant bits of the source file:

    Error 1

    Error: Rank mismatch in argument ‘mess’ at (1) (rank-1 and scalar) datcom.f:9165:21:

    9165 | & 4HRE ,1,ROUTID)

    datcom.f lines 9164-9165 and relevant variable declarations:

    SUBROUTINE EQSPCE(X,R,P,S,NP,XE,RE,PE,SE,NE,DSEDX)
    !
    !*** TRANSFORMS 4-DIMENSIONAL ARRAY SO THAT THE 3 INDEPENDENT ARRAYS
    ! ARE EQUALLY SPACED
    !
    DIMENSION ROUTID(2)
    DIMENSION CR(6),CP(6),CS(6)
    DIMENSION X(1),R(1),P(1),S(1),XE(1),RE(1),PE(1),SE(1), &
    & DSEDX(20)
    DIMENSION VAR(4),LGH(4)
    DATA ROUTID/4HEQSP,4HCE /
    CALL INTERX(1,X,VAR,LGH,R,RE(I),NP,NP,0,0,0,0,0,0,0,0, &
    & 4HRE ,1,ROUTID)

    interx procedure interface:

    SUBROUTINE INTERX (NIND,TABLE,VAR,LENGTH,DEP,ANS,LIND,LDEP, &
    & LX1L,LX2L,LX3L,LX4L,LX1U,LX2U,LX3U,LX4U,MESS,NMSS,ROUT)
    DIMENSION MSSCL(21),RMSCL(21)
    DIMENSION LENGTH(4),TABLE(LIND,4),DEP(LDEP),VAR(4),ROUT(2), &
    & MESS(20)
    EQUIVALENCE(MSSCL(1),RMSCL(1))
    DATA MSSCL /4HINTE,4HRX ,19*0/
    DATA SRPMSS /4H1TIN/,HOL1/4H1EXP/


    Error 2

    Error: Type mismatch in argument ‘x2’ at (1); passed LOGICAL(4) to REAL(4)
    datcom.f:1245:72:

    1245 | & DATA(5),DATA(6),DATA(7),DATA(8),DATA(9),P,Q,R,S,T,NN,NM)


    Error 3

    Error: Actual argument contains too few elements for dummy argument ‘kol’ (1/80) at (1)
    datcom.f:40352:36:

    40352 | IF(LDM(I) .GT. 0) CALL RVALUE(KOL,L,NDML,NF,BLANK, &
    | 1

    More information about datcom can be found in the links below.

    What is Datcom?: https://www.pdas.com/datcom.html

    How to download and compile the source code: https://www.pdas.com/datcomdownload.html


    The source code from the PDAS site is truly horrible. It appears to be
    Fortran IV code, with some casual declarations of a few variables as of
    type CHARACTER (which did not exist in Fortran IV) thrown in.

    Here are two examples of troublesome code in Datcom.f:

    Subroutine SWRITE has the second dummy argument declared as of type CHARACTER(4). There are several calls to SWRITE elsewhere in which the corresponding actual argument is of type REAL (by default typing). Thus,
    the hidden length parameter that is passed along with CHARACTER type
    actual arguments by many current compilers is not passed at the calling
    points.

    In block data BLOCKD, we have the declaration

    COMMON /CONSNT/ CONST(5)

    and then this:

    DATA CONST / 3.141592654,0.01745329,1.E-30,57.2957795,4H$ /

    Thus, elements 1:4 are initialized with real values (Pi, Pi/180, 1E-30
    180/Pi), but the 5th element is initialized with a Hollerith constant.

    -- CyrMag

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to CyrMag on Sun Oct 24 12:18:43 2021
    On Sunday, October 24, 2021 at 7:51:48 AM UTC-7, CyrMag wrote:

    (snip)

    The source code from the PDAS site is truly horrible. It appears to be Fortran IV code, with some casual declarations of a few variables as of
    type CHARACTER (which did not exist in Fortran IV) thrown in.

    Here are two examples of troublesome code in Datcom.f:

    Subroutine SWRITE has the second dummy argument declared as of type CHARACTER(4). There are several calls to SWRITE elsewhere in which the corresponding actual argument is of type REAL (by default typing). Thus,
    the hidden length parameter that is passed along with CHARACTER type
    actual arguments by many current compilers is not passed at the calling points.

    In block data BLOCKD, we have the declaration

    COMMON /CONSNT/ CONST(5)

    and then this:

    DATA CONST / 3.141592654,0.01745329,1.E-30,57.2957795,4H$ /

    Thus, elements 1:4 are initialized with real values (Pi, Pi/180, 1E-30 180/Pi), but the 5th element is initialized with a Hollerith constant.

    The one one Github compiled (with lots of warnings) on the first try,
    and ran the test file on the first try. I don't know that the results are right, but it ran without problems.

    Last year, I compiled and ran both ECAP and SPICE 2 with gfortran.
    Both are, more or less, Fortran IV. (Among others, Fortran IV allows
    Hollerith constants with apostrophes, but gfortran doesn't. I had
    to change them all to H constants.)

    Most of the warnings are from initializing REAL variables with H
    constants. (In ECAP, SPICE2, and this one.) I didn't check through
    the warnings so carefully, though.

    It might be nice to have one properly converted to using
    CHARACTER, but as you note, halfway is not so good.

    The hidden length argument is only needed for CHARACTER*(*),
    as well as I know. I do agree, though, that it shouldn't be done
    that way.

    From the original post, though, it looks like it uses free-form
    continuation lines. (Spacing doesn't go through the newsgroup
    well enough to tell more than that.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Mon Oct 25 05:40:50 2021
    gah4 <gah4@u.washington.edu> schrieb:

    The hidden length argument is only needed for CHARACTER*(*),
    as well as I know. I do agree, though, that it shouldn't be done
    that way.

    There are combinations of gfortran versions and optimization
    options where this was not the case. It is always a bad idea to
    violate the ABI, and it bit some people. See the case of R being
    miscompiled because the length was left out of the C bindings and
    the compiler assumed there was enough space for a tail call.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From CyrMag@21:1/5 to Thomas Koenig on Mon Oct 25 01:16:33 2021
    On Monday, October 25, 2021 at 12:40:53 AM UTC-5, Thomas Koenig wrote:
    gah4 <ga...@u.washington.edu> schrieb:
    The hidden length argument is only needed for CHARACTER*(*),
    as well as I know. I do agree, though, that it shouldn't be done
    that way.
    There are combinations of gfortran versions and optimization
    options where this was not the case. It is always a bad idea to
    violate the ABI, and it bit some people. See the case of R being
    miscompiled because the length was left out of the C bindings and
    the compiler assumed there was enough space for a tail call.

    Indeed. Consider how the compiler has to translate the called subprogram, assuming separate compilation. The subroutine has a character dummy argument, with length (*) or an explicit length. It is expected that this subroutine will be called with a
    corresponding character argument. The compiler's ABI conventions require that passing the hidden length (or another mechanism) be done consistently, because when compiling the caller there is no available interface to tell whether the dummy argument has
    len=* or len=<a known integer constant value>. In the latter case, the length argument may not be needed, but it still occupies a place on the stack, and its presence may affect the locations of other (non-character) arguments on the stack.

    With the old compilers FPS4 from Microsoft and CVF6 from Digital/Compaq, the STDCALL name decoration for the subroutine in question is @84 in the caller when a real actual argument is (improperly) passed and @88 when a character argument is passed. The
    name decoration of the callee is @88, and the link step fails when FPS4 is used, with SWRITE@88 reported to be a missing external symbol.

    If the compiler uses mixed string-length arguments, as FPS4 did, the arrangement of the actual arguments on the stack will be incorrect, regardless of whether the lengths are needed in the callee or not.

    --CyrMag

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to CyrMag on Mon Oct 25 02:33:42 2021
    On Monday, October 25, 2021 at 1:16:35 AM UTC-7, CyrMag wrote:

    (snip)

    With the old compilers FPS4 from Microsoft and CVF6 from Digital/Compaq,
    the STDCALL name decoration for the subroutine in question is @84 in the caller when a real actual argument is (improperly) passed and @88 when a character argument is passed.

    STDCALL is even worse than that. The 8086 has an instruction that pops some words
    off the stack, and then returns. That allows for the called routine to do it, which means
    it is done in only one place, instead of each call. But that only works if all use the same
    size stack frame.

    However, with variable argument functions, C doesn't work well with STDCALL, and so
    CDECL was invented. Now most use it for Fortran, allowing calls between Fortran and C.

    While calling a CHARACTER dummy argument with a REAL actual argument isn't required to work by the standard, using a Hollerith constant for an actual argument
    has to work with both CHARACTER and other, such as REAL, dummy arguments.
    Some years ago, I learned how VAX/VMS does this. VAX uses pass by descriptor for CHARACTER arguments, where the descriptor includes the address and length.

    As you note, in the case of separate compilation, the calling routine doesn't know
    what the called routine expects. The VAX/VMS solution is for the linker to fix this one up! Since the compiler can't know, that is the only choice.

    In any case, mixing old and new is complicated, and one must be careful!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)