Do not try ancient PGI hacks with recent versions of that compiler

should fix #2139

Fix errors in cpu affinity setup with glibc 2.6

for #2114

Misc. typo fixes in comments and documentation

fixes #2104

Found via `codespell -q 3 -w -L ith,als,dum,nd,amin,nto,wis,ba -S ./relapack,./kernel,./lapack-netlib`

pool cleanup upon THREAD_DETACH which is needed when compiled with
USE_TLS=1.

Add CPUID data for Intel Denverton (as Nehalem)

Do not compile in AVX512 check if AVX support is disabled

xgetbv is function depends on NO_AVX being undefined - we could change that too, but that combo is unlikely to work anyway

Address warning in memory.c

Correct range limiting in trmv_thread and re-enable TRMV multithreading

Restore locking optimizations for OpenMP case

restore another accidentally dropped part of #1468 that was missed in #2004 to address performance regression reported in #1461

same bug as seen in #1388, somehow missed in corresponding PR #1389

* Fix potential memory leak in cpu enumeration with glibc

An early return after a failed call to sched_getaffinity would leak the previously allocated cpu_set_t. Wrong calculation of the size argument in that call increased the likelyhood of that failure. Fixes #2003

* Restore dropped patches in the non-TLS branch of memory.c

As discovered in #2002, the reintroduction of the "original" non-TLS version of memory.c as an alternate branch had inadvertently used ba1f91f rather than a8002e2 , thereby dropping the commits for #1450, #1468, #1501, #1504 and #1520.

Move TLS key deletion to openblas_quit

fixes #1954 (as suggested by thrasibule in that issue)

Re-enable loop unrolling in trmv and remove the scary warning

fixes #1748 as that half of the fix for #1332 appears to have been an overreaction on my part.

Delete the pthread key on cleanup in TLS mode

to avoid a crash when OpenBLAS was loaded via dlopen and libc tries to clean up the leaked TLS after dlclose
Fixes #1720

Fixes #1924 where numpy 1.17+ would report the (transient) FE_INVALID exception raised for the domain error.

cf. #1908

Serialize accesses to parallelized level3 functions from multiple cal…

for #1851

fixes #1872

otherwise the introduction of a static array in 8e5a108 to improve #532 breaks concurrent calls from multiple threads as seen in #1844

The current gemm threading code can make very unfortunate choices, for
example on my 10 core system a 1024x1024x1024 matrix multiply ends up
chunking into blocks of 102... which is not a vector friendly size
and performance ends up horrible.

this patch adds a helper define where an architecture can specify
a preference for size multiples.
This is different from existing defines that are minimum sizes and such.

The performance increase with this patch for the 1024x1024x1024 sgemm
is 2.3x (!!)