Compilation problem with Interface, Procedure

[htg20]

Hi all,
Could someone tell me why ifort 14.0.1.106 does not compile this code below. Gfortran and I think NAG compile this. If this is not standard, could you indicate the part of the standard that prohibits this? Thank you.

Cheers

Hossein

module iface

  interface foo
    subroutine i_sub_foo(v)
      integer, intent(inout) :: v(:)
    end subroutine i_sub_foo
  end interface foo
  interface bar
    procedure i_sub_foo
  end interface bar
end module iface

Error msg: iface.f90(10): error #6623: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit.   [I_SUB_FOO]

[Lorri_M_Intel · Accepted solution]

This is fixed in the upcoming 15.0 release, coming later this year.

           --Lorri

[htg20]

Thank you very much. One more thing; while ago I reported a compiler problem (ifort 12,13) with the 'PSBLAS' code (  http://www.ce.uniroma2.it/psblas/ ) . Later another user reported same problems with getting the 'internal compiler error'. Ifort 14 can compile PSBLAS but it fails to run some of the subroutines because of taking the wrong interfaces. Is it possible to check this code with upcoming Ifort 15 to see if there exist other bugs too? 

[Ron_Green]

There are too many codes for Intel to test all of them.  We encourage users of application and the developer/maintainers of applications to join our beta programs - the compilers are free and usable for several weeks after the final release of the product.  Feel free to download a copy of 15.0 beta and try it yourself:

Try out the new Intel® Software Development Tools 2015 Beta and help make our product better. Registration is easy through the https://softwareproductsurvey.intel.com/survey/150347/2afa/ site. Additional information can be found at http://bit.ly/sw-dev-tools-2015-beta.

ron

[htg20]

Well, I will do this. However, about PSBLAS, it is an F2003 code which ifort has many problems compiling it from couple of years ago that I'm aware of. Other compilers gfortran, Cray, NAG, and I think IBM can compile it. So I think it worth looking at it in more detail. Anyhow, I will share with you the results of trying it with V15.

[Izaak_Beekman]

htg20 wrote:

Well, I will do this. However, about PSBLAS, it is an F2003 code which ifort has many problems compiling it from couple of years ago that I'm aware of. Other compilers gfortran, Cray, NAG, and I think IBM can compile it. So I think it worth looking at it in more detail. Anyhow, I will share with you the results of trying it with V15.

Keep in mind that Intel’s Fortran compiler does not claim to be completely F2003 compliant. If you’re seeing ICEs or failure to compile or correctly run with supported F2003 features then that is indeed a problem. Also, you might need to add compiler flags like -standard-semantics and/or -stand f03 if the code relies on certain F2003 features.

[htg20]

These are bugs which are there for couple of years now and not only some unsupported F2003 feature. I tested the Beta version of ifort 15 and both compiler bugs persist (the one reported here and the bugs with PSBLAS). How we can proceed now? I have located the problem with PSBLAS  and can report.

[Steven_L_Intel1]

If you'll identify the PSBLAS source file names that have problems, and tell us what the error message is, we'll investigate.

[htg20]

I started with the test/pargen/ppde2e.f90 to track the problem.

I have recognized the problems in the file "psblas-3.1.2-1/base/serial/impl/psb_d_mat_impl.F90 " and probably same thing occurs in the similar files.  The first runtime crash happens near line 640 where it tries to do: call a%set_bld() and I replaced it "Call psb_d_set_bld(a)" which fixed the problem. The second problem occurs near the line 760 where the original code is "call a%a%csput(nz,ia,ja,val,imin,imax,jmin,jmax,info,gtl)". I replaced it with the code below which fixed the runtime crash. Obviously I coded what the compiler had to do. Other instances of crash happen in the same file more or less for the same reasons.

  if (allocated(a%a)) then
      selecttype (the_class => a%a)

      class is (psb_d_coo_sparse_mat)
         call psb_d_coo_csput(nz,ia,ja,val,the_class,imin,imax,jmin,jmax,info,gtl)
      class is (psb_d_csc_sparse_mat)
         print *, 'psb_d_csc_sparse_mat is the class'
      class is (psb_d_csr_sparse_mat)
         print *, 'psb_d_csr_sparse_mat is the class'
      end select

   else
      STOP 'psb_d_csput: This is not allocated'
  endif

[Ron_Green]

what does your configure string contain?

[htg20]

Nothing especial. I use Openmpi for the mpi library, and make sure the environmental variables for mpif90, ifort are load and then run the configure command with no additional argument.

[Ron_Green]

in particular, how do you select blas from MKL?   --with-blas=<mkl path>/lib???.a   ??

[htg20]

I do not use MKL at all; so I use the BLAS from the system. I use ubuntu 14.04 x64.  Below is my configuration result.

PSBLAS 3.0 has been configured as follows:

       MPF90                 : mpifort
    MPF77                 : mpifort
    MPCC                  : mpicc
    FLINK                 : mpifort

    FDEFINES              : -DHAVE_LAPACK -DHAVE_MOLD -DHAVE_EXTENDS_TYPE_OF -DHAVE_SAME_TYPE_AS -DHAVE_FINAL -DHAVE_ISO_FORTRAN_ENV -DHAVE_FLUSH_STMT -DHAVE_VOLATILE -DHAVE_ISO_C_BINDING -DHAVE_MOVE_ALLOC -DMPI_MOD 
    CDEFINES              : -DLowerUnderscore -DPtr64Bits 
    MODEXT                : .mod
    FMFLAG                : -I
       F90COPT               : -O3 
       FCOPT                 : -O3 
       CCOPT                 : -O3 

    BLAS                  : -lblas

    METIS detected        : 
    AMD detected          : 

        LIBS                  :  

    LDLIBS                : 

    LIBRARYPATH           : 
    INCLUDEPATH           : 
    MODULE_PATH            : 

[Ron_Green]

I'd like to see your configure command, something like this (which is not working)

./configure FC=ifort F77=ifort CC=icc MPF90=mpiifort MPF77=mpiifort MPCC=mpiicc --with-blas=/cts/tools/compiler/cpro/Compiler/15.0/up2-064/composer_xe_2015.0.064/mkl/lib/intel64/libmkl_core.a

The system BLAS is dog slow, we really don't want to use that lib.  Default blas is unacceptable IMHO.  Perhaps I can help figure out how to get MKL to be used.  I did see a thread on the MKL forum on this, but the Intel engineer pretty much threw up his hands and said 'no idea' or 'doesn't work with MKL'.  I'll see if I can get someone else from that team engaged.

ron

[htg20]

Dear Ron,

I understand but I only run ' ./configure  '. That is all (assuming that the mpif90, etc. will run ifort and not gfortran - I mean all of the environment values are loaded properly). You might even consider compiling it in the serial mode to get rid of the MPI dependency.

Also, it does not matter if it is slow or what Blas code it uses. The test item is somewhere else where the compiler fails and not the efficiency.

[Ron_Green]

The BLAS library may matter - I'll have to find an Ubuntu system and pull down the blas packages and lapack packages.  But these are built for GFORTRAN, and not Intel Fortran.  These 2 compilers are not compatible - different calling conventions.  So if you're using a library built for gfortran and calling from IFORT, it will link but you will indeed get runtime seg faults at function calls.

So for IFORT, the options are to build netlib blas from sources using ifort and use that lib, or if we can figure out how to get the configure script to recognize and use the MKL ifort blas libs.

[Ron_Green]

I've built OpenBLAS with the Intel 15.0 Beta compilers, and built PSBLAS.  How do you run ppde2d? 

I'm running with just

mpirun -n 16 ./ppde2d

it seems to either be taking a long time or expecting input.  Are there any command line args needed?

ron

[Ron_Green]

Ok, so I found the .inp file after having to read through the code to see what it was doing (documentation would have helped)

mpirun -n 4 ./ppde2d < ppde.inp

does this look OK?

[htg20]

You should give an input file. In the "psblas/test/pargen/runs" folder, there is a sample input file ppde.inp. In Linux you can do something like this. After doing this, the program will crash after doing some prelaminary steps.

mpirun -np 2 ./ppde2d < ppde.inp

[htg20]

Yes, please have a look at my previous post (htg20 Mon, 06/16/2014 - 00:44) regarding the source of compiler bug.