Skip to content

Latest commit

 

History

History
113 lines (87 loc) · 4.71 KB

ISSUES.md

File metadata and controls

113 lines (87 loc) · 4.71 KB
Raw

Issues using FlexiBLAS

Last Update: Jun 16, 2020

Table of Contents

  1. Profiling Numpy/Scipy with linked against FlexiBLAS

  2. CBLAS Tests with ATLAS and MKL

  3. Building software with FlexiBLAS

  4. FlexiBLAS-API is not linked.

  5. Crash with LAPACK interface on IBM Power

  6. CBLAS Interface of BLIS

  7. Building with pre-built BLAS and LAPACK on MacOSX

  8. gcc >= 10.0 and LAPACK 3.7/3.8

  9. Profiling Numpy/Scipy with linked against FlexiBLAS

Due to the default behaviour of Python to open C-API modules with LAZY and local binding, not all FlexiBLAS related symbols are integrated correctly in the current address space. The profiling will not count all function calls correctly. Many of them will be passed directly to the loaded backend bypassing the wrapper interface. Changing Python's default behaviour using sys.setdlopenflags may help in this case but it is not guaranteed.

Solution: Compile and link Numpy/SciPy and all related packages against fleixblas-profile and load flexiblas-profile again via LD_PRELOAD.

  1. CBLAS Tests with ATLAS and MKL

Due to some diffuclt internals of ATLAS and MKL it is not possible to call 'make test' for the CBLAS interface if ATLAS or MKL is used as BLAS backend.

Solution: Select Netlib or OpenBLAS to perform those tests.

  1. Building software with FlexiBLAS

The configuration systems GNU autotools and CMake sometimes perform some strange tests to check if the BLAS libraries are working correctly and if they support 64 bit integers or not. Therefore it is the best to use the NETLIB backend druing the configuration. This can be easily achieved by setting the FLEXIBLAS or the FLEXIBLAS64 environment variable to "NETLIB" before starting the configuration process.

  1. FlexiBLAS-API is not linked

If the FlexiBLAS-API library is used and the BLAS library is FlexiBLAS than libflexiblas_api is not linked against your code if flexiblas_api comes after flexiblas in the linker command line. The correct order is

gcc .... -lflexiblas_api -lflexiblas ...

or in general

gcc .... -lflexiblas_api -lblas ...

in order to avoid problems when switching the BLAS library via update-alternatives or similar tool. The reason for this behavior is that the flexiblas_api library and the flexiblas library have some common symbols which do not get resolved if flexiblas_api appear after flexiblas in the linking order.

  1. Crash with LAPACK interface on IBM Power

If FlexiBLAS is compiled on the ppc64 or ppc64le with the help of the gcc compiler (up to version 5.4.0 and 6.3.0) most likely it will crash when calling an LAPACK function. The reason behind this is a code generation bug inside many version of gcc. It prevents that recursive function calls work over shared object boundaries. More detailed information about this bug can be found in the following bug tracker entries:

There are two solution for this problem. On the one hand one can use the PGI Compiler Suite for OpenPOWER (the community edition is available at no cost) and compile FlexiBLAS using the PGI Compiler. This compiler correctly handles the recursive calls.

Otherwise one can use an gcc from svn. The svn revision need to be at least r245930. In the upcoming gcc versions this problem will be fixed.

  1. CBLAS Interface of BLIS

The CBLAS wrapper in the BLIS library contains a call to exit in its cblas_xerbla implementation. This might alter the behavoir of a program and let the CBLAS tests fail. For this reason FlexiBLAS does not load the BLIS-CBLAS interface if it detects the BLIS library.

  1. Building with pre-built BLAS and LAPACK on MacOSX

The ilaenv and iparam2stage routine from the reference LAPACK implementation can cause an faulty memory access due to a copy operation with changing array length. The LAPACK/BLAS reference BLAS and LAPACK implementation shipped with FlexiBLAS fixes this error. On other systems this error was not detectable yet.

  1. gcc >= 10.0 and LAPACK 3.7/3.8

The testing code for LAPACK 3.7.x and 3.8.0 contains some legacy Fortran codes that require the -fallow-argument-mismatch flag on recent GNU Fortran version. Beginning with gcc/gfortran 10.1.0 this flags needs to be set via

cmake ........ -DCMAKE_Fortran_FLAGS="-fallow-argument-mismatch"

while configuring FlexiBLAS. Alternatively, the tests can be disabled.