blas_server_avail was read without holding server_lock. If multiple threads call blas_thread_shutdown simultaneously, for example, by calling fork(), then they can attempt to shut down multiple times. This can lead to a segmentation fault.

Fix get_num_procs()  in the USE_TLS branch for non-glibc systems

add embedded option

Fix null pointer check in blas_memory_alloc

fixes #3074

Add CPUID information for Intel Rocket Lake

Power10 fixes

1. Using core loongson3r3 and loongson3r4 for loongson
2. Add DYNAMIC_ARCH for loongson

Change-Id: I1c6b54dbeca3a0cc31d1222af36a7e9bd6ab54c1

ARM64 DYNAMIC_ARCH build fix for BSD/OSX

After a fork it is possible that blas_thread_buffer has already
allocated memory buffers: goto_set_num_threads does allocate those
already and it may be called by num_cpu_avail in case the OpenBLAS
NUM_THREADS differ from the OMP num threads.
This leads to a memory leak which can cause subsequent execution of BLAS
kernels to fail.

Fixes #2993

If the toolchain is too old, or the mma features isn't set on a POWER10
fall back to the POWER9 loops.

Improve the performance of rot by using AVX512 and AVX2 intrinsic

fix avx2 detection

reword commits to make it clearer

1. Add a new API -- sbgemv to support bfloat16 based gemv
2. Implement a generic kernel for sbgemv
3. Implement an avx512-bf16 based kernel for sbgemv

Signed-off-by: Chen, Guobing <guobing.chen@intel.com>

Try to read cpu ID from /sys/devices/.../cpu0 if HWCAP_CPUID fails

to be able to include a binutils version check

Avoid out of bounds access on invalid memory free

Lazyly reinit threads after a fork in OMP mode

This initializes the per-thread memory buffers which get
cleared/released on a fork via pthread_at_fork. Not doing so leads to
each thread calling blas_memory_alloc on almost every execution which
slows down the code significantly as the threads race for the memory
allocation using locks to serialize that.