gfortran 11 gives errors

[dimpase]

This was originally reported as oseledets/ttpy#82 - but is can also be reproduced directly here.

% make
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c nan.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c timef.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c say.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c rnd.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c ptype.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c sort.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c trans.f90
gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c ort.f90
ort.f90:270:23:

  270 |    call dgemv('t',n,ru,1.d0,u,n,x,1, 0.d0,gu,1)
      |                       1
......
  346 |     call dgemv('n',n,ru,-one,u,n,gu,1, one,x,1)
      |                        2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(8)/COMPLEX(8)).
ort.f90:271:22:

  271 |    call dgemv('t',n,r,1.d0,yy,n,x,1, 0.d0,gv,1)
      |                      1
......
  346 |     call dgemv('n',n,ru,-one,u,n,gu,1, one,x,1)
      |                        2
...
... more of these

[dimpase]

The problem is that in some of the calls to dgemv COMPLEX types are used, e.g. on l.346 one is COMPLEX, but on
l.270 the corresponding 4th and 9th parameters are DOUBLE.

By right, dgemv does not take COMPLEX, for these one must use cgemv.
I suppose the solution is just to replace one with a DOUBLE.

[dimpase]

Hmm, no, sorry, some of the calls to dgemv are really on the COMPLEX arrays. Do they meant to be calls to zgemv ?

[dimpase]

I guess the following is the correct change:

--- a/ort.f90
+++ b/ort.f90
@@ -343,8 +343,8 @@ contains
    do while(reort.and.pass.lt.3)
     call zgemv('c',n,ru,one,u,n,x,1, zero,gu,1)
     call zgemv('c',n,r,one,yy,n,x,1, zero,gv,1)
-    call dgemv('n',n,ru,-one,u,n,gu,1, one,x,1)
-    call dgemv('n',n,r,-one,yy,n,gv,1, one,x,1)
+    call dgemv('n',n,ru,realpart(-one),realpart(u),n,realpart(gu),1, realpart(one),realpart(x),1)
+    call dgemv('n',n,r,realpart(-one),realpart(yy),n,realpart(gv),1, realpart(one),realpart(x),1)
     bb(1:ru,j)=bb(1:ru,j)+gu; bb(ru+1:ru+r,j)=bb(ru+1:ru+r,j)+gv(1:r)
     nrm1=nrm2; nrm2=dznrm2(n,x,1); reort=nrm2.lt.nrm1/2; pass=pass+1
    end do

---

the next obstacle is

gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c matrix_util.f90
matrix_util.f90:184:32:

  184 |        call zcopy(m, A(i,1), n, C(1,i),1)
      |                                1
......
  321 |        call zcopy(n1*n2*n3, C, 1, A, 1)
      |                                  2
Error: Element of assumed-shape or pointer array as actual argument at (1) cannot correspond to actual argument at (2)
matrix_util.f90:164:32:

  164 |        call dcopy(m, A(i,1), n, C(1,i),1)
      |                                1
......
  297 |        call dcopy(n1*n2*n3, C, 1, A, 1)
      |                                  2
Error: Element of assumed-shape or pointer array as actual argument at (1) cannot correspond to actual argument at (2)

[dolgov]

grep -R orto_z ./
./ort.f90: module procedure orto_d,orto_z
./ort.f90: subroutine orto_z(u,v,out,mat)

It seems that orto_z is some very old legacy that is used nowhere actually, but indeed all MMs should be zgemv there. Committed zgemv just to make it compile.

[dolgov]

Re second error, it seems there is either a bug or a paranoid feature in gfortran >=10 (https://gitmemory.com/issue/cp2k/dbcsr/377/712700623) that treats passing elements as a reference to address as an error. It's best to find which gfortran flag reverts to the legacy fortran, but I don't have gcc 11 to experiment with.

[dimpase]

On Fri, Jun 18, 2021 at 6:56 PM dolgov ***@***.***> wrote: Re second error, it seems there is either a bug or a paranoid feature in gfortran >=10 (https://gitmemory.com/issue/cp2k/dbcsr/377/712700623) that treats passing elements as a reference to address as an error. It's best to find which gfortran flag reverts to the legacy fortran, but I don't have gcc 11 to experiment with.

I am not sure - it might be the result of stricter imposition of Fortran 90 syntax. That link refers to gfortran 10, but this is gfortran 11. Type checking does not come for free. The real problem seems to be the lack of an interface description for Lapack, something akin to https://github.com/certik/fortran-utils/blob/master/src/lapack.f90

[dolgov]

cp2k/cp2k#1157 (comment)

[dolgov]

GCC 9 lacks the option -fallow-argument-mismatch. Please create a new preset in Makefile.in for GCC 11.