Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Lapack Lite lapack_testing fail

munakata
Beginner
854 Views
Dear user

I tried compile lapack lite 3.1.1 with ifort 10.1.008 for MacOSX on Leopard(XCode 3.0). Building lapack library was succeeded, but failed on sgebal xeigtesits in lapack_testing.

Testing log was
SGEBAL: Testing the balancing of a REAL general matrix
./xeigtsts sbal.out 2>&1
make[1]: *** [sbal.out] Error 174
make: *** [lapack_testing] Error 2

The sbal.out at the time of the error seemed to be next :
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
xeigtsts 00243693 Unknown Unknown Unknown
xeigtsts 00242B2F Unknown Unknown Unknown
xeigtsts 0020BAA4 Unknown Unknown Unknown
xeigtsts 001E2CFC Unknown Unknown Unknown
xeigtsts 001E989C Unknown Unknown Unknown
libSystem.B.dylib 95B8A97B Unknown Unknown Unknown
Unknown FFFFFFFF Unknown Unknown Unknown
xeigtsts 001F730B Unknown Unknown Unknown
xeigtsts 0001730F Unknown Unknown Unknown
xeigtsts 000033F4 Unknown Unknown Unknown
xeigtsts 00002442 Unknown Unknown Unknown
xeigtsts 000023FC Unknown Unknown Unknown
xeigtsts 00002329 Unknown Unknown Unknown
Unknown 00000001 Unknown Unknown Unknown



used lapack lite make.inc is :
FORTRAN = ifort -m32
OPTS = -O2 DRVOPTS = $(OPTS)
NOOPT = -O0
LOADER = ifort -m32
LOADOPTS = -L/opt/intel/fc/10.1.008/lib

Does anyone know a fix for this problem?

Thanks.
Myu
0 Kudos
1 Reply
md2581
Beginner
854 Views
I have a similar problem on a brand new Mac cluster.



I started compiling the reference BLAS and the
library was generated. Then I compiled the lapack-lite-3.1.1 up
against the reference BLAS. Again, no problem, the libraries are
generated.... BUT... in the testing phase of the Makefile the
following happened....

... after a while ...
./xeigtstc < cgd.in > cgd.out 2>&1
CHB: Testing Hermitian Eigenvalue Problem routines
./xeigtstc < csb.in > csb.out 2>&1
CSG: Testing Symmetric Generalized Eigenvalue Problem routines
./xeigtstc < csg.in > csg.out 2>&1
CGEBAL: Testing the balancing of a COMPLEX general matrix
./xeigtstc < cbal.in > cbal.out 2>&1
make[1]: *** [cbal.out] Error 174
make: *** [lapack_testing] Error 2

... That means that there was a runtime error. The file
TESTING/cbal.out holds the console output of that particular test
function, and here's what it says:

# cat TESTING/sgbal.out

Message Catalog System: corrupt file.Message Catalog System: corrupt file.forrtl: severe (174): SIGSEGV, segmentation fault occurred

Furthermore,

# ifort -V

Intel Fortran Compiler for applications running on Intel 64, Version 10.1 Build 20080312 Package ID: m_fc_p_10.1.014
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

# uname -a

Darwin portal.cluster.private 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386

# cd TESTING
# gdb xeigtsts

GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .... done

(gdb) run < sbak.in
Starting program: /Users/mads/producer/lapack-lite-3.1.1/TESTING/xeigtsts < sbak.in
Reading symbols for shared libraries +++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000100ffffff
0x00000001001cfbad in for__get_s ()

... so the debugger thinks that KERN_INVALID_ADDRESS is the problem. ?

here's my make.inc (I was currently testing the -heap-arrays option)

FORTRAN = ifort
OPTS = -heap-arrays
DRVOPTS = $(OPTS)
NOOPT = -heap-arrays -fltconsistency -fp_port
LOADER = ifort
LOADOPTS =


/ Mads

0 Kudos
Reply