| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
069a5c3188 FindLAPACK: SCSL also has LAPACK routines
dbcc5eaa05 FindBLAS: Update SCSL library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6402
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With Cray compiler wrappers (implicitly tested on OLCF Spock) the
BLAS and LAPACK libraries are automatically linked as necessary through
the wrapper script and programming environment. With this change, the
configure output is:
```
-- Found BLAS: implicitly linked
<snip>
-- Found LAPACK: implicitly linked
```
rather than
```
-- Found BLAS: 1
<snip>
-- Found LAPACK: LAPACK_LIBRARIES-PLACEHOLDER-FOR-EMPTY-LIBRARIES
```
|
|
|
|
|
|
|
|
|
|
|
|
| |
Logic added by commit 4c74c86f40 (FindBLAS/LAPACK: Add support for the
Fujitsu SSL2 library, 2021-01-27, v3.21.0-rc1~402^2~1) accidentally
expressed a boolean condition without proper grouping. The pattern was
then copied by commit 2c9e623e31 (Find{BLAS,LAPACK}: Add support for the
NVHPC LAPACK library, 2021-05-05, v3.21.0-rc1~192^2). The resulting
logic incorrectly tries Fujitsu and NVHPC vendors even after results are
found from another vendor, and then erases those. Fix the grouping.
Fixes: #22403
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5bf1651452 Find{BLAS,LAPACK}: Revise and extend Intel MKL usage documentation
8585a12bd9 Find{BLAS,LAPACK}: Move enabled language requirement to top of documentation
6a7c055f96 Find{BLAS,LAPACK}: Revise formatting of intro docs
43b581367d Find{BLAS,LAPACK}: Move implementation note from docs to comments
3beac78a13 Find{BLAS,LAPACK}: Revise imported targets documentation layout
6f305cd5fd Find{BLAS,LAPACK}: Factor out vendor documentation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6218
|
| |
| |
| |
| | |
Fixes: #22295
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Move the list of vendors to a dedicated section shared by both modules.
Format it as a definition list.
|
|/
|
|
|
| |
Add search paths for the Intel oneAPI MKL directory structure
so that we do not rely on paths in `LD_LIBRARY_PATH`.
|
| |
|
|
|
|
| |
Fixes: #21071
|
|
|
|
|
|
|
|
| |
Now that `CHECK_{BLAS,LAPACK}_LIBRARIES` are functions, we can set
`CMAKE_FIND_LIBRARY_SUFFIXES` locally without affecting the global
state. This avoids the need for local state switching that was added in
commit 9ef82d95d8 (FindBLAS: Fix detection of OpenMP as dependency of
BLA_STATIC, 2021-04-07, v3.20.1~3^2), so remove that.
|
|
|
|
|
| |
Now that `CHECK_{BLAS,LAPACK}_LIBRARIES` are functions, we can set
`CMAKE_REQUIRED_QUIET` locally without affecting the global state.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactoring in commit 4c74c86f40 (FindBLAS/LAPACK: Add support for the
Fujitsu SSL2 library, 2021-01-27) was done in order to support calling
`find_library` on the dependencies as well as the candidate libraries.
However, it broke a few things:
* Intel MKL's BLAS/LAPACK are no longer found. We specify their
dependencies using `-l...` flags, so we should not try to use
`find_library` for them.
* The dependencies are repeated because we accumulate them in the
`find_library` search loop and then append them at the end too.
Revert the incorrect part of the refactoring. Retain the flags part
needed for the Fujitsu vendor.
Fixes: #22056
|
|
|
|
|
|
|
|
| |
This also does some additional work to fix issues with
libraries provided only via compiler options and no explicit
library names.
Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
|
|
|
|
|
|
| |
- mimic FindBLAS
Fixes: #21700
|
|
|
|
| |
http://mossigplan.acm.org/EML_introduction_engl.pdf
|
|
|
|
| |
Issue: #19715
|
|
|
|
| |
http://www.mpi-magdeburg.mpg.de/mpcsc/software/FlexiBLAS/
|
|
|
|
| |
LAPACK previously used custom and verbose output messages.
|
|\
| |
| |
| |
| |
| |
| |
| | |
196f042b58 FindLAPACK: Handle Windows Intel MKLROOT with backslash
96c19ecd55 FindBLAS: Handle Windows Intel MKLROOT with backslash
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4982
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The patch also updates the documentation to explicitly state
that Intel10_32 stands for threaded case (linked with Intel OpenMP).
Later, one may need to add Intel10_32_seq to support linking
with the sequential version of Intel MKL.
Fixes: #20857
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though Intel MKL typically puts the libraries under
`$MKLROOT/lib/$arch_$os` some installations may still use
`$MKLROOT/lib/$arch/` path. Ideally, `$arch` should be a
symlink to `$arch_$os`, but sometimes the opposite happens
(for instance, see Intel MKL distribution in Arch Linux [1]),
and sometimes only `$arch` directory alone is present.
This patch extends the search list with `$MKLROOT/lib/$arch` with
lower priority than `$MKLROOT/lib/$arch_$os`, as the latter is the
official path to Intel MKL libraries.
It is also worth mentioning that Intel MKL Link Line Adviser [2]
recommends using `$MKLROOT/lib/$arch` directory in a link line:
```
-L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_intel_lp64
-lmkl_sequential -lmkl_core -lpthread -lm -ldl
```
[1] https://www.archlinux.org/packages/community/x86_64/intel-mkl/files/
[2] https://software.intel.com/content/www/us/en/develop/articles/intel-mkl-link-line-advisor.html
|
| |
|
|
|
|
|
|
|
| |
Add support for the Arm Performance Libraries (ArmPL) which provide an
implementation of BLAS, LAPACK and FFTW for use on Arm Linux systems:
https://developer.arm.com/tools-and-software/server-and-hpc/compile/arm-compiler-for-linux/arm-performance-libraries
|
|
|
|
|
|
|
| |
This is required if MKLROOT points to the subdirectory .../mkl/ instead of
the root of an Intel MKL library installation. Only in this case the MKL
will be searched starting from the parent directory, to detect relevant
dependencies in parallel subdirectories, like 'compiler' and 'tbb'.
|
| |
|