Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.

Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.

Imagen de Dirk B.

Hi,

this is my firstcontribution here. I experienced some strange behaviour of ifort 13.0.1, compared to 12.1.x or other FORTRAN compilers (gfortran, IBM...) so I think it's a bug. ifort 13.0.1 does not recognize the difference between these two subroutines within a generic interface block:

  INTERFACE my_proc
   MODULE PROCEDURE my_proc_2d
    MODULE PROCEDURE my_proc_3d
  END INTERFACE

CONTAINS

  SUBROUTINE my_proc_2d(a2)
  REAL(wp), INTENT(INOUT) :: a2(:,:)
! body of proc
END SUBROUTINE my_proc_2d

  SUBROUTINE my_proc_3d(a3)
  REAL(wp), INTENT(INOUT) :: a3(:,:,:)
! body of proc
END SUBROUTINE my_proc_3d

The compiler does not seem to make a difference between a 2D- and a 3D-array. I'd like to know wether this is to be fixed in the near future...

Regards,

Dirk Barbi

publicaciones de 12 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Steve Lionel (Intel)

Please show a small but complete program that demonstrates the problem. I haven't been able to construct a program that fails based on the excerpt you posted.

Steve
Imagen de Dirk B.

Hi Steve,

somehow I can't see your comment in the forum, only in the e-mail. Something's weird with your homepage...

I attach a test case. Runs with 12.0.3, fails with 13.

Regards,
Dirk

Adjuntos: 

Imagen de Steve Lionel (Intel)

Something seems to have happened to the older replies. I don't see a problem with the 13.0.1 compiler - the calls are properly distinguished and no compiletime error occurs. This is with the code in the base post. I will have to find out what happened to the other replies.

Steve
Imagen de Dirk B.

Hi Steve,

I still can only see my original post.

However, I checked again, witch the same result, 13.0.1 does not compile the files I sent you. I'm using the following Makefile:
(sorry, Makefiles can't be uploaded)

FC = ifort

default: test.o

prog: mo_my_interface.o mo_wrapper1.o mo_wrapper2.o test.o Makefile
$(FC) -o gen_interface_test.x mo_wrapper1.o mo_wrapper2.o mo_my_interface.o test.o

test.o: mo_my_interface.o mo_wrapper1.o mo_wrapper2.o test.f90
$(FC) -c test.f90

mo_my_interface.o: mo_my_interface.f90
$(FC) -c mo_my_interface.f90

mo_wrapper1.o: mo_my_interface.o mo_wrapper1.f90
$(FC) -c mo_wrapper1.f90

mo_wrapper2.o: mo_my_interface.o mo_wrapper2.f90
$(FC) -c mo_wrapper2.f90

clean:
rm *.o *.mod

Thanks,
Dirk

Imagen de Dirk B.

Hi again,

I see all posts when I change to the German site, http://software.intel.com/de-de/node/339276 .

Dirk

Imagen de Dirk B.

Hi a last time for today,

just wanted to inform you: also when I call ifort with just

ifort mo_my_interface.f90 mo_wrapper2.f90 mo_wrapper1.f90 test.f90 -o test.x

I get the error:

test.f90(12): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [MY_PROC]
call my_proc(a2)
-------^
test.f90(20): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [MY_PROC]
call my_proc(a3)
---------^

???

Dirk

Imagen de Steve Lionel (Intel)

Ok, now that I can see the whole test program, I can reproduce the error. The paraphrased excerpt from the original post was not sufficient to show it.

The problem is triggered by the use mo_my_interface in module mo_wrapper2. For some reason, this use, without the only:my_proc, triggers the error. It shouldn't and I will report this to the developers and let you know of any progress.

There are two workarounds. The most obvious is to remove the "only" clause from the use of mo_my_interface in the main program, as this is rendered moot by the lack of an only clause in mo_wrapper2. An alternative is to add "only: my_proc" in mo_wrapper2.

Steve
Imagen de Dirk B.

Hi Steve,

good to know that you see the same now. Thanks for keeping me informed if there is a bugfix; concerning the workarounds, I will use them for the time being, and also report them to the project manager of the ocean model that shows this behaviour. Alas, I'm not the one to maintain the code, so I can't make a permanent change to the code without good reason, and I doubt that an ifort error is considered a good reason...

Thanks again!

Dirk

Imagen de Steve Lionel (Intel)

This has been escalated as issue DPD200239376. I will let you know of any progress.

Steve
Imagen de Steve Lionel (Intel)

I expect this problem to be fixed in Update 4, planned for late June.

Steve
Imagen de Steve Lionel (Intel)

My apologies - this problem is not going to be fixed in Update 4, but will be fixed in a release later this year.

Steve

Inicie sesión para dejar un comentario.