MinGW - error message using "make"

[benjicre97]

TL;DR Summary

MinGW - Error message during installation when writing "make"

Hello, I have a problem using MinGW. When I write "make" during the installation, this error appears :

$make
cd ./src;make
make[1]: Entering directory '/home/benji/auto/07p/src'
gfortran -fopenmp -O -c maps.f90 -o ../lib/maps.o
maps.f90:97:41:

97 | DFDP(1,ICP(J)),1,1d0,DFDP1(1,ICP(J)),1)
| 1
. . . . . .
257 | CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0,DFDV(1,NDM+1),1)
|
Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(8)/INTEGER(4)).
make[1]: *** [Makefile:48: ../lib/maps.o] Error 1
make[1]: Leaving directory '/home/benji/auto/07p/src'
make: *** [Makefile:14: src] Error 2

I read a lot of things to find the problem but I cannot find any solution..
Hope someone can help me..

Thanks in advance for your time

 

[Arjan82]

If you call the same function twice in your code, but in the first you use a REAL(8) as argument somewhere, but in the second call you use a different type (INTEGER(4)) at the same place in the function call, then this error pops up (it is a relatively recent added error I understand), that's what it complains about. You can apparently circumvent this by using this compiler option: -fallow-argument-mismatch.

Better would be to use the same type always and thus do some type casting.

See also
https://stackoverflow.com/questions...smatch-between-two-unrelated-subroutine-calls

 

[benjicre97]

If you call the same function twice in your code, but in the first you use a REAL(8) as argument somewhere, but in the second call you use a different type (INTEGER(4)) at the same place in the function call, then this error pops up (it is a relatively recent added error I understand), that's what it complains about. You can apparently circumvent this by using this compiler option: -fallow-argument-mismatch.

Better would be to use the same type always and thus do some type casting.

See also
https://stackoverflow.com/questions...smatch-between-two-unrelated-subroutine-calls

Hello,

I didn't enter REAL or INTEGER, it was during the installation so I only had to write "make" for the first time but I probably found the problem, it comes from an error in a file where I had to replace "CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0,DFDV(1,NDM+1),1)" by "CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0d0,DFDV(1,NDM+1),1)"

Thanks for your reponse

 

[pbuk]

I didn't enter REAL or INTEGER,

! 0 in the line below is an integer.
CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0,DFDV(1,NDM+1),1)
! 0d0 in the line below is a (double precision) real.
CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0d0,DFDV(1,NDM+1),1)

 

[Mark44]

it comes from an error in a file where I had to replace
"CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0,DFDV(1,NDM+1),1)"
by
"CALL DGEMV('n',NDM,NDM,F,DFDU,NDM,U(NDM+1),1,0d0,DFDV(1,NDM+1),1)"

My absolutely biggest gripe about Fortran is not so much about the language itself, but about those who program in it. My intent is not to pick on the OP in this thread, as he/she is probably mimicking existing code that was previously written by programmers who had no concept of what makes code easy to read and understand, and thereby easier to fix bugs in and maintain.

Specific gripes:

• All variables are too short to convey any idea of what they're supposed to represent. This applies to function names as well, but there's not much one can do about it when using an API written by someone else, possibly 40+ years ago.
• Other than the required space right after CALL, there is not a single other space in either line of code.
• All variables are in all caps. This was probably required in the Fortran IV/Fortran 77 days, but that's 45 years ago, and Fortran has thankfully moved on.

 

[benjicre97]

My absolutely biggest gripe about Fortran is not so much about the language itself, but about those who program in it. My intent is not to pick on the OP in this thread, as he/she is probably mimicking existing code that was previously written by programmers who had no concept of what makes code easy to read and understand, and thereby easier to fix bugs in and maintain.

Specific gripes:

• All variables are too short to convey any idea of what they're supposed to represent. This applies to function names as well, but there's not much one can do about it when using an API written by someone else, possibly 40+ years ago.
• Other than the required space right after CALL, there is not a single other space in either line of code.
• All variables are in all caps. This was probably required in the Fortran IV/Fortran 77 days, but that's 45 years ago, and Fortran has thankfully moved on.

It's my first time with Fortran and yeah it is pretty hard to read what the guy that write the code.
It comes from "Auto-07p" that allows to compute orbites for a 3-body problem.

 

[pbuk]

Specific gripes:

• All variables are too short to convey any idea of what they're supposed to represent. This applies to function names as well, but there's not much one can do about it when using an API written by someone else, possibly 40+ years ago.

I don't know what you are talking about, DGEMV was only written 35 years ago and the API is obvious, you only have to read the documentation.

Oh. . Maybe not.

 

[Arjan82]

Specific gripes:

• All variables are too short to convey any idea of what they're supposed to represent. This applies to function names as well, but there's not much one can do about it when using an API written by someone else, possibly 40+ years ago.
• Other than the required space right after CALL, there is not a single other space in either line of code.
• All variables are in all caps. This was probably required in the Fortran IV/Fortran 77 days, but that's 45 years ago, and Fortran has thankfully moved on.

I hear you... I sometimes have to deal with Fortran70 code written in, well the 70ties and 80ties, which, besides the above also has poor or no documentation... Some random excerpt ():

      Q0=((ETA*PD*1000.0*PI*PI*D**4/16.0)/(ZETA*0.5*RHO))**0.3333333333
      DO 200 I=1,14
      Q=0.1*FLOAT(I)*Q0
      RH=Q*(Q*Q*0.5*RHO*ZETA/(0.25*PI*D*D)**2+DH*G*RHO)
      IF(RH.GT.PD*1000.0*ETA.AND.I.GT.1) THEN
C       SOLVE Q
        DO 120 J=1,60
        QH=Q
        Q=0.5*(Q+QV)
        RH=Q*(Q*Q*0.5*RHO*ZETA/(0.25*PI*D*D)**2+DH*G*RHO)
        IF(ABS(RH-PD*1000.0*ETA).LT.0.01*PD) GOTO 201
        IF(RH.LT.PD*1000.0*ETA) THEN
          QV=Q
          Q=QH
        ENDIF
 120    CONTINUE
        PRINT*,' *** NO CONVERGENCE'
        GOTO 5
      ELSE
        IF(RH.GT.PD*1000.0*ETA.AND.I.EQ.1) THEN
          PRINT*,' *** NO VOLUME FLOW; TOO GREAT HEAD REQUIRED'
          GOTO 5
        ENDIF
        QV=Q
      ENDIF
  200 CONTINUE
      PRINT*,' *** TOO LARGE NEGATIVE ADDITIONAL HEAD'
      GOTO 5
  201 CONTINUE

 

[anorlunda]

Early FORTRAN was worse than many imagine. One thing that used to drive me crazy was that FORTRAN ignored spaces. In the code below, the first line is the start of a DO loop. The second line sets the variable DO10I to the value 110.

DO 10 I = 1,10
DO 10 I = 1 10

The other big problem was COMMON declarations. In the years before the compilers allowed an INCLUDE or INSERT feature, COMMON declarations had to be written by hand in every module that used them. A simply typo in anyone of those could cause the compile to be successful, but the COMMON declarations to misalign with other uses. Again and again, we had to trace bugs by comparing the
COMMON declarations in module after module.

The programmers of those days used COMMON to implement heap and stack like features by manipulating the COMMON. That was a terrible way to do it, but there were no heap or stack features available.

Here's a good trivia meant to reveal which of us really did program in FORTRAN's early days. IBM FORTRAN had a type of statement in the language called FREQUENCY. Who knows what a FREQUENCY statement did?

 

[Mark44]

Here's a good trivia meant to reveal which of us really did program in FORTRAN's early days. IBM FORTRAN had a type of statement in the language called FREQUENCY. Who knows what a FREQUENCY statement did?

I have to admit that I'd never heard of this statement, as my earliest foray into Fortran was Fortran 77. Apparently the FREQUENCY statement was available in the Fortran compiler for the IBM 704, as documented in this user manual dating back to 1956. See https://archive.computerhistory.org/resources/text/Fortran/102649787.05.01.acc.pdf, on p. 37.

 

[hmmm27]

What's the difference between the FREQUENCY statement and "simply" hard coding for frequency-of-occurence ?

 

[Mark44]

What's the difference between the FREQUENCY statement and "simply" hard coding for frequency-of-occurence ?

The link I provided shows how this statement is used. I'm not sure I get what you mean by " hard coding for frequency-of-occurrence."

 

[hmmm27]

Sry, missed the link : coding for foc is ordering compound conditionals from highest to least likely, ie: if you were doing a letter count of a page, it would run faster (in English) to see if the letter's an 'e', first, rather than an 'a'.

 

[Mark44]

I don't know what you are talking about, DGEMV was only written 35 years ago and the API is obvious, you only have to read the documentation.

Sure, obvious, like this explanation for the very first parameter of DGEMV:

TRANS is CHARACTER*1
On entry, TRANS specifies the operation to be performed as
follows:

TRANS = 'N' or 'n' y := alpha*A*x + beta*y.

TRANS = 'T' or 't' y := alpha*A**T*x + beta*y.

TRANS = 'C' or 'c' y := alpha*A**T*x + beta*y.

No explanation that I could find on any difference between 'T' and 'C'.

 

[pbuk]

Sure, obvious, like this explanation for the very first parameter of DGEMV:

No explanation that I could find on any difference between 'T' and 'C'.

The amount of time it wastes detecting whether the code is compiled for an EBCDIC, ASCII or ASCII with HI bit 7 environment?