Makefile.arm | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 use flags suitable for armhf port when target=armv6
 See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
 Also, if we don't explicitly set the -march and -mfpu flags, the resulting
 static libraries crash with SIGILL (reason not yet elucidated).

Makefile.system | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 various fixes for kfreebsd shared library
 Under kFreeBSD, give a SONAME to the shared library and install it. Also link
 it against libm.
 Simply use the same code as Linux for all these operations.

driver/others/blas_server.c | 10 0 + 10 - 0 !
1 file changed, 10 deletions(-)

 remove warning about openmp
 This warning is annoying when the library is built with pthreads.
 See #684344

Makefile | 100 12 + 88 - 0 !
Makefile.install | 9 0 + 9 - 0 !
Makefile.system | 2 0 + 2 - 0 !
interface/Makefile | 8 8 + 0 - 0 !
4 files changed, 20 insertions(+), 99 deletions(-)

 adapt build system for the absence of lapack-netlib/ and relapack directories.
 Instead use the binary provided by package liblapack-pic, stripping from it the
 symbols that are overridden by OpenBLAS.

interface/Makefile | 25 25 + 0 - 0 !
1 file changed, 25 insertions(+)

 create shared libraries lib{blas,lapack}.so.3
 * It is done so that duplicate code with libopenblas.so.0 is kept as low as
   possible. Only the symbols from the external BLAS/LAPACK API are incorporated
   in the shared libraries. The rest is obtained by dynamic linking against
   libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in

exports/gensymbol | 74 0 + 74 - 0 !
1 file changed, 74 deletions(-)

 matgen symbols are not included in debian binary
 The libopenblas binaries do not include libmatgen code, so don't mark them as
 exported and don't test for their presence (in linktest).

exports/gensymbol | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 when building libjulia-openblas64, we place the lapack shared
 objects under lapack64-netlib/ directory. But if exports/gensymbol cannot
 detect the existence of the lapack-netlib directory, it will skip the lapack
 symbol which results in incomplete symbol mangling (SYMBOLSUFFIX=64_) through
 objcopy.

getarch.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

---

driver/others/dynamic_arm64.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix sigill on arm64 when hwcap_cpuid is not set
 This is a crashing bug (SIGILL) that also affects numpy on arm64. One 
 line of processors affected are NVIDIA Tegra (Jetson devices).
 .
 On ARM64, openblas uses feature registers to detect the detailed 
 processor arch. It queries HWCAP_CPUID to check if the feature registers 
 are used. But due to a missing volatile declaration, gcc seems to break 
 this guarding in optimization.

Makefile.prebuild | 3 2 + 1 - 0 !
c_check | 4 2 + 2 - 0 !
getarch.c | 8 0 + 8 - 0 !
3 files changed, 4 insertions(+), 11 deletions(-)

 fix incorrect results of avx512 dgemm kernel when built on pre-avx2 machine
 When building OpenBLAS with dynamic arch selection on x86-64 hardware
 that does not support AVX2 (e.g. Intel Ivybridge or earlier), then
 the AVX512 (SkylakeX) kernel for DGEMM would produce incorrect
 results (of course when run on AVX512-capable hardware).
 .
 The problem was that the check for determining whether the compiler
 is able to understand AVX512 assembly/intrinsics was doubly
 incorrect: it would test the build machine capabilities (instead of
 the compiler capabilities); and it would check for AVX2 instead of
 AVX512. As a consequence, on pre-AVX2 hardware, the build system
 would conclude that the compiler is not able to understand AVX512
 primitives, and would create a broken AVX512 (SkylakeX) DGEMM kernel
 (essentially a Haswell kernel, but with some wrong assumptions, hence
 leading to incorrect numerical results).