topic Well, I will do this. However in Intel® Fortran Compiler

Compilation problem with Interface, Procedure

htg20 — Thu, 12 Jun 2014 11:06:35 GMT

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]

This is fixed in the upcoming

Lorri_M_Intel — Thu, 12 Jun 2014 11:28:25 GMT

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

--Lorri

Thank you very much. One more

htg20 — Thu, 12 Jun 2014 11:47:22 GMT

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?

There are too many codes for

Ron_Green — Fri, 13 Jun 2014 15:22:20 GMT

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

Well, I will do this. However

htg20 — Fri, 13 Jun 2014 15:40:32 GMT

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.

Quote:htg20 wrote:

Izaak_Beekman — Sat, 14 Jun 2014 01:08:03 GMT

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.

These are bugs which are

htg20 — Sun, 15 Jun 2014 10:42:53 GMT

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.

If you'll identify the PSBLAS

Steven_L_Intel1 — Sun, 15 Jun 2014 23:32:16 GMT

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

I started with the test

htg20 — Mon, 16 Jun 2014 07:44:55 GMT

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

what does your configure

Ron_Green — Tue, 17 Jun 2014 15:10:33 GMT

what does your configure string contain?

Nothing especial. I use

htg20 — Tue, 17 Jun 2014 15:25:27 GMT

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.

in particular, how do you

Ron_Green — Tue, 17 Jun 2014 15:30:12 GMT

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

I do not use MKL at all; so I

htg20 — Tue, 17 Jun 2014 15:37:46 GMT

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 :

I'd like to see your

Ron_Green — Tue, 17 Jun 2014 16:22:29 GMT

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

Dear Ron,

htg20 — Tue, 17 Jun 2014 16:45:25 GMT

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.

The BLAS library may matter -

Ron_Green — Tue, 17 Jun 2014 17:08:52 GMT

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.

I've built OpenBLAS with the

Ron_Green — Tue, 01 Jul 2014 16:14:54 GMT

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

Ok, so I found the .inp file

Ron_Green — Tue, 01 Jul 2014 16:29:46 GMT

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?

You should give an input file

htg20 — Tue, 01 Jul 2014 16:32:52 GMT

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

Yes, please have a look at my

htg20 — Tue, 01 Jul 2014 16:35:25 GMT

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