When running the LAPACK tests that come with the reference LAPACK library from netlib with MKL 10 (10.0.1.14 and 10.0.2.18), the tests produce a segmentation fault.
The tests check the error exits, so they pass parameters to LAPACK routines that are not valid to see if the routine will identify an error. This seems to be causing the segmentation faults in the iterative refinement (e,g, DGERFS) and condition estimation (e.g. DGECON) LAPACK routines.
A segmentation fault also occurs if the routines like DGECON are called with N=0, which is a valid imput parameter.
When I change the input file for the tests so it does not run the error exit tests and all dimensions are greater than zero, then the tests pass successfully.
The system I am using is running Redhat 4 64-bit and has a dual core Pentium 2.80 GHZ processor. Tests are being compiled with Intel Fortran version 10.0.023 compilers. MKL libraries used in link line are -lmkl -lmkl_lapack -lguide -lpthread.
Any advice?
The tests check the error exits, so they pass parameters to LAPACK routines that are not valid to see if the routine will identify an error. This seems to be causing the segmentation faults in the iterative refinement (e,g, DGERFS) and condition estimation (e.g. DGECON) LAPACK routines.
A segmentation fault also occurs if the routines like DGECON are called with N=0, which is a valid imput parameter.
When I change the input file for the tests so it does not run the error exit tests and all dimensions are greater than zero, then the tests pass successfully.
The system I am using is running Redhat 4 64-bit and has a dual core Pentium 2.80 GHZ processor. Tests are being compiled with Intel Fortran version 10.0.023 compilers. MKL libraries used in link line are -lmkl -lmkl_lapack -lguide -lpthread.
Any advice?
連結已複製
4 回應
A minor nitpick: You shouldn't need to link libraries more than once, by using both the libmkl and the libmkl_lapack scripts. It shouldn't be harmful, given that it should make an MKL 9.1 link sequence work.
It seems that error handling should be consistent with reference lapack; if this interests you, file a problem report on premier.intel.com
It seems that error handling should be consistent with reference lapack; if this interests you, file a problem report on premier.intel.com
I know it's hardly a consolation but ditto for gerfs and gecon on Windows. Genuine Lapack 3 has been available since ca 2000 iirc so why hasn't Intel got its variant of it to perform without seg faults and access violations?
Gerry
