This patch replaces all instances of “int” by “CBLAS_INT” in CBLAS/testing/*.c
(except for RowMajorStrg which has must remain an “int”, since it is declared
as such in CBLAS main code).
Interestingly, the bug would not manifest on low endian architectures,
because interpreting an int64_t pointer as an int32_t pointer works there (as
long as the integers fits in 31 bits, which is the case here). But on big
endian architectures, this of course fails badly.
cblas.h defines
double cblas_dcabs1(const void *z);
float cblas_scabs1(const void *c);
but does not provide an implementation. This commit adds
the missing implementation in the common CBLAS style and
eliminates the linker error when calling the above function.
long's in windows are 4 bytes (MSVS, intel compilers). Use int64_t and int32_t
to ensure 8 byte integers for ILP interface.
support 8 byte integer flag for intel ifort compiler
Commits 2d9fbdeecc and
628a2095c2 changed the function prototypes in the
cblas_f77.h.
However, the F77_xerbla case was not treated in the same way as the others. In
particular, the consequence is now that the xerbla function provided by the
CBLAS/src/xerbla.c file is never called at runtime (because it is identified as
“F77_xerbla” in the symbol table, instead of simply “xerbla”, since F77_xerbla
is *not* a macro).
This patch restores the symmetry between xerbla and the other functions.
The variable $< should only be used when a suffix rule applies.
Otherwise, GNU Make extends its meaning to be the first prerequisite.
Avoid using it that way for portability.
This reverts commit 7fb9b8f128.
Allows us to use the built-in suffix rules where appropriate.
FORTRAN -> FC (POSIX)
OPTS -> FFLAGS (POSIX)
DRVOPTS -> FFLAGS_DRV
NOOPT -> FFLAGS_NOOPT
LOADER -> FC (use the compiler driver for linking)
LOADOPTS -> LDFLAGS (POSIX)
ARCH -> AR (POSIX)
ARCHFLAGS -> ARFLAGS (POSIX)
* Distributions might need to change the header dir
* Also change the template paths in the `.pc` files to
the idiomatic CMake `GNUInstallDirs` full paths,
which are always correct, regardless of whether the
user specified relative or absolute paths. This makes
the build system somewhat easier and more idiomatic.
cleanobj: Remove object files
cleanlib: Remove libraries
cleanexe: Remove test and example executables
cleantest: Remove test output and core dumps
clean: All of the above
Maria Kraynyuk