Community
cancel
Showing results for 
Search instead for 
Did you mean: 
peterwriesnik
Beginner
144 Views

Linking with MKL produces Segmentation Fault

Jump to solution
Hello everybody!

I'm quite new to using MKL-routines. I thought the easiest way of linking might be using the -mkl option on the ifort compiler as described here (http://software.intel.com/sites/products/documentation/studio/composer/en-us/2009/compiler_c/copts/common_options/option_mkl.htm). I tried the following minimal example:
[bash]module test_mod use mkl95_PRECISION use mkl95_LAPACK contains subroutine routine double precision :: D(4),E(3) D=(/1,2,3,4/) E=(/1,2,3/) call stedc(D,E) write (*,*) D end subroutine end module program main use test_mod call routine end program[/bash]
Compiling with ifort -mkl compiles, but running the binary produces segmentations faults due to the error "MKL ERROR: Parameter 1 was incorrect on entry to DSTEDC". Changing the data type to real or complex does not solve the problem. On the other hand, if i compile the same code using "call dstedc_mkl95(D,E)" instead of "call stedc(D,E)" with the following makefile
[bash]#------------------------------------------------------------------------------- IFACE_LIB=$(MKLPATH)/libmkl_intel_lp64.a THREADING_LIB=$(MKLPATH)/libmkl_intel_thread.a OMP_LIB = -L/opt/intel/lib -liomp5 CORE_LIB=$(MKLPATH)/libmkl_core.a LAPACK_LIB=$(MKLPATH)/libmkl_lapack95_lp64.a I64_INCLUDE=$(MKLINCLUDE)/intel64/lp64 MKL_LIBS=$(LAPACK_LIB) $(IFACE_LIB) $(THREADING_LIB) $(CORE_LIB) $(THREADING_LIB) $(CORE_LIB) $(THREADING_LIB) $(CORE_LIB) $(OMP_LIB) #------------------------------------------------------------------------------- test.out: test.f90 ifort -I $(I64_INCLUDE) -w $< $(MKL_LIBS) -lpthread -o test.out #-------------------------------------------------------------------------------[/bash]
everything works great. But this way i can't compile complex routines, only real and double precision. What am I doing wrong? I thought -mkl was all i needed to get the whole MKL working...
Thank you in advance!
BTW: I am using ifort 12.0.0 with composer XE 2011.0.085 on Mac OS X 10.7.3 Lion
0 Kudos
1 Solution
mecej4
Black Belt
144 Views
> I thought -mkl was all i needed to get the whole MKL working.

Only for the simplest instances of using MKL. In particular, that will not work if you make Lapack95 calls, as you did in your example. Consult the MKL Link Line Advisor.

Your example (21 source lines) compiles and runs when compiled on Windows 7 x64:

ifort /Qmkl xsted.f90 mkl_lapack95_lp64.lib

and produces the output

-0.742393758888324 0.852282288303725 2.96827628913336
6.92183518145124

View solution in original post

8 Replies
mecej4
Black Belt
145 Views
> I thought -mkl was all i needed to get the whole MKL working.

Only for the simplest instances of using MKL. In particular, that will not work if you make Lapack95 calls, as you did in your example. Consult the MKL Link Line Advisor.

Your example (21 source lines) compiles and runs when compiled on Windows 7 x64:

ifort /Qmkl xsted.f90 mkl_lapack95_lp64.lib

and produces the output

-0.742393758888324 0.852282288303725 2.96827628913336
6.92183518145124

View solution in original post

Gennady_F_Intel
Moderator
144 Views
I have also checked the result with the latest 10.3.update 9 but on linux64 bit - the same result as mecej4 reported.
peterwriesnik
Beginner
144 Views
how where your compiler settings?
peterwriesnik
Beginner
144 Views
using the settings
ifort -mkl test.f90 /opt/intel/mkl/lib/libmkl_lapack95_lp64.a
for compiling on Mac OS produces segmentation faults as well.
barragan_villanueva_
Valued Contributor I
144 Views

On my (10.2.0 Darwin Kernel Version 10.2.0) machine the test works OK

% ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1 Build 20120321
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

% ifort test.f90 -mkl -I$MKLROOT/include/intel64/lp64 $MKLROOT/lib/libmkl_lapack95_lp64.a
% ./a.out
-0.742393758888324 0.852282288303725 2.96827628913336
6.92183518145124

peterwriesnik
Beginner
144 Views
Thank you for all the great answers! They really helped a lot. Using the Link Line Advisor solved the problem, I got it working. Now i tried splitting the whole program into modules since that would appear in most of my use-cases. The main file "test.f90" looks like
[bash]program main use test_mod call routine end program[/bash]
The module "test_mod" is defined in the file "test_mod.f90" which looks like
[bash]module test_mod use mkl95_PRECISION use mkl95_LAPACK contains subroutine routine complex :: D(4),E(3) D=(/1,2,3,4/) E=(/1,2,3/) call stedc(D,E) write (*,*) D end subroutine end module[/bash]
I am compiling and linking the whole thing with the following makefile
[bash]LINKFLAGS=-L$(MKLROOT)/lib $(MKLROOT)/lib/libmkl_blas95_ilp64.a $(MKLROOT)/lib/libmkl_lapack95_ilp64.a -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread -lm CFLAGS=-i8 -I$(MKLROOT)/include/intel64/ilp64 -I$(MKLROOT)/include -xSSSE3 -axSSSE3 #------------------------------------------------------------------------------- test.out: test.o ifort *.o $(LINKFLAGS) -o test.out test.o: test_mod.o ifort -c $(CFLAGS) test.f90 -o test.o test_mod.o: ifort test_mod.f90 $(CFLAGS) -c -o test_mod.o clean: rm -rf *.mod *.o *.out [/bash]
The linkline is from the Link Line Advisor. Everything works fine, linking errors and segmentation faults don't appear anymore. But now I stumbled across an new problem: If I change the type of D and E from double precision to complex, the complex routine cstedc() should be called instead of dstedc() (seehttp://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/mklxe/mkl_manual_win_mac/lse/functn_stedc.htm). But it doesn't. I get an error telling that the complex routine does not exist with a message similar to "check the include paths". I tried a few other routines where the F95 interface should determine the routine to be called by checking the type of the variables and it worked. I got complex and double precision routines working by just changing the type of data passed to a generic interface.
Is it possible that there isn't an interface to every lapack-routine implemented in lapack95? Or am I misunderstanding this whole thing?
Thank you in advance!
barragan_villanueva_
Valued Contributor I
144 Views
Is it possible that there isn't an interface to every lapack-routine implemented in lapack95? Or am I misunderstanding this whole thing?


Hi,

For FORTRAN 95 interface for LAPACK please look at $MKLROOT/include/lapack.f90 file
(it is used by you via compiler option -I$(MKLROOT)/include/intel64/ilp64)

Also, please look at Fortran interface for LAPACK in $MKLROOT/include/mkl_lapack.fi file

mecej4
Black Belt
144 Views
When you use the Fortran 95 interfaces, the information in the MKL95 modules is used to disambiguate the generic names into specific routine names. Thus, for the code in your original post, the call to STEDC is resolved by a call to ZSTEDC_MKL95.

However, in #6 you called the generic name with two COMPLEX arguments. As you can see from the MKL documentation for STEDC, the first two arguments must be REAL or DOUBLE PRECISION arrays in all instances, and there is no matching case for arrays of type COMPLEX as the first two arguments. This explains the error message.

It is true that not every Lapack routine has a Fortran 95 counterpart in Lapack95. Lapack has been revised a few times after Lapack95 was published, and no corresponding updates were published for Lapack95. However, this is not a relevant factor for the present thread.

Note that there are actually two generic names for STEDC: RSTEDC and STEDC. In the original post, since you used the latter, the call was directed to ZSTEDC_MKL95.

You may find it helpful to view the table Computational Routines for Solving Symmetric Eigenvalue Problems and the accompanying diagrams Decision Tree: Real Symmetric Eigenvalue Problems and Decision Tree: Complex Hermitian Eigenvalue Problems in the MKL reference manual.
Reply