segfaults with dstemr

[Mark_Muller]

I have run into segfaults when using dstemr and wonder if anyone else has seen similar problems. I can produce the error with a trivial example in either fortran or C++. Below is a fortran example:

[cpp]program test_stemr

implicit none
integer i,j,k,il,iu
integer size,info,nev,nzc,lwork,liwork

real(kind=8) vl,vu,abstol
real(kind=8), allocatable :: D(:),E(:),Lambda(:),Phi(:,:),work(:)
integer, allocatable :: iwork(:),isuppz(:)
logical tryac

size = 100
write(*,*) "working on size = ",size
allocate(D(size),E(size))
do i=1,size
  D(i) = i
  E(i) = 0.0
end do
allocate(Lambda(size),Phi(size,size),isuppz(2*size))
liwork = 10*size
lwork = 18*size
allocate(iwork(liwork),work(lwork))

nzc = size
tryac = .true.
vl = 1.99
vu = 18.1
il = 0
iu = 0
call dstemr("V","V",size,D,E,vl,vu,il,iu,nev,Lambda,Phi,size,nzc, &
            isuppz,tryac,work,lwork,iwork,liwork,info)

write(*,*) "after stemr"
write(*,*) 'info   = ',info
write(*,*) 'nzc    = ',nzc
write(*,*) 'nev    = ',nev
write(*,*) 'eigenvalues are: ',(lambda(i),i=1,nev)
write(*,*)

deallocate(work,iwork,isuppz,Lambda,Phi,D,E)

write(*,*) "done with test_stemr"

end program test_stemr[/cpp]

When I compile this using v11.1 (056) of the Intel compilers on an x86_64 machine (ie, ifort tes.tf90 -mkl) and run it, I get the following output:

[cpp] working on size =          100
 after stemr
 info   =            0
 nzc    =            2
 nev    =           17
 eigenvalues are:    2.00000000000000        3.00000000000000     
   4.00000000000000        5.00000000000000        6.00000000000000     
   7.00000000000000        8.00000000000000        9.00000000000000     
   10.0000000000000        11.0000000000000        12.0000000000000     
   13.0000000000000        14.0000000000000        15.0000000000000     
   16.0000000000000        17.0000000000000        18.0000000000000     
 
 done with test_stemr
Segmentation fault
[/cpp]

The segfault is occurring at the very end of the program. In more real world cases, the segfaults occur after calling dstemr, but before the final exit. If I change the range argument (argument #2) from "V" to "A", I never have any problems. I get the same problem if I use dstegr in place of dstemr, which is unsurprising this dstegr is just a wrapper around dstemr. I also notice that the input variable nzc is changed, where the description of the routine lists it as input, not input/output or output.

Is anyone using dstemr with the "V" option for the range and having any luck? Searching around I have found very little discussion of dstemr/dstegr in any context and would appreciate hearing from any users/

Regards,
Mark Muller

[Gennady_F_Intel]

Mark,
It seems to me this is the error with dstemv implementaion. We need to check more carefully the problem on our side.
--Gennady

[Gennady_F_Intel]

Hi Mark,

Yes this is the problem dealt with lp64 interfaces. We will fix it asap.
As a temporarily workaround rebuild your application with ilp64 libraries.
--Gennady

[Mark_Muller]

Quoting - Gennady Fedorov (Intel)

Hi Mark,

Yes this is the problem dealt with lp64 interfaces. We will fix it asap.
As a temporarily workaround rebuild your application with ilp64 libraries.
--Gennady

Thanks for the info. Nice to know it isn't just me.

I am having some trouble using the ilp64 libraries. With Fortran, it looks like everything works by doing:

ifort -integer-size 64 -c test.f90
ifort -integer-size 64 test.o /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_ilp64.a /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_ilp64.a /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.a /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_core.a

C++ as been giving me problems. I don't see a way with the C++ compiler to make the default int 64 bits. Am I missing something? Or should I just put in a conversion of int to mkl_int64 in everyone of my lapack/blas wrappers?

Thanks again,
Mark Muller

[Gennady_F_Intel]

Quoting - Mark Muller

Quoting - Gennady Fedorov (Intel)

Hi Mark,

Yes this is the problem dealt with lp64 interfaces. We will fix it asap.
As a temporarily workaround rebuild your application with ilp64 libraries.
--Gennady

Thanks for the info. Nice to know it isn't just me.

I am having some trouble using the ilp64 libraries. With Fortran, it looks like everything works by doing:

ifort -integer-size 64 -c test.f90
ifort -integer-size 64 test.o /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_ilp64.a /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_ilp64.a /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.a /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_core.a

C++ as been giving me problems. I don't see a way with the C++ compiler to make the default int 64 bits. Am I missing something? Or should I just put in a conversion of int to mkl_int64 in everyone of my lapack/blas wrappers?

Thanks again,
Mark Muller

Mark,
for compiling iLP64 Interfaces by C/C++ compiler please use /DMKL_ILP64 option.
for more info, refer to the Users's Guide, chapter 3.
--Gennady

[Gennady_F_Intel · Accepted solution]

Quoting - Gennady Fedorov (Intel)

Mark,
for compiling iLP64 Interfaces by C/C++ compiler please use /DMKL_ILP64 option.
for more info, refer to the Users's Guide, chapter 3.
--Gennady

Hello Mark,
Intel MKL 10.2 Update 3 is now available.
The problem discussed into this tread has been fixed into this update.
Please see the Intel MKL 10.2 Update 3 is now available announce. You can find there the link to the Intel registration center to download. Could you please let us know if the problem is still exists?
--Gennady