Re: New BLAS/LAPACK system

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Thu, 5 Nov 2020 11:28:42 -0600
schrieb Jason Bacon <outpaddling%yahoo.com@localhost>: 

> This issue might affect other platforms as well, if they use a base
> cc and c++ with pkgsrc gfortran.  On Linux, C, C++, and Fortran
> typically all come from the same place, either the Linux distro's
> packages or pkgsrc.

I don't see me being able to help with that one. I will not willingly
try to mix a self-built gfortran with another version of gcc/g++ in the
system. It's a compiler collection. Can we discuss if it's a sensible
use-case to just build gfortran as add-on in the first place? For sure,
that is something that is rarely tested anyways.

Best would be to push for a base OS that provides C and C++ from GCC to
also provide Fortran. Anything more than plain C should bring the whole
bunch to be consistent. But if this somehow can be worked out in
pkgsrc, fine. I just feel unable/unwilling to help with that process:-/

To be fair: I just now see trouble building OpenBLAS with my system GCC
10. Test programs segfault, I first suspected this warning:

   92 |       COMPLEX*16         A( NMAX, NMAX ), AA( NMAX*NMAX ),
      |                                                         1
Warning: Array 'aa' at (1) is larger than limit set by
'-fmax-stack-var-size=', moved from stack to static storage. This makes
the procedure unsafe when called recursively, or concurrently from
multiple threads. Consider using '-frecursive', or increase the
'-fmax-stack-var-size=' limit, or change the code to use an ALLOCATABLE
array. [-Wsurprising] zblat2.f:93:55:

But while looking scary (and I am inclined to add -frecursive to my
FCFLAGS), it's not the issue. Rather a version bump on OpenBLAS seems
to be needed to avoid a segfault in the cblat1 test.

	https://github.com/xianyi/OpenBLAS/issues/2382

Version 0.3.12 is current. We have 0.3.7. But 0.3.12 also fails for me
due to this:

	https://github.com/xianyi/OpenBLAS/issues/2971

So -mavx in CFLAGS is needed here. Apparently, a newer release will fix
that. I'm trying 0.3.10 now, trying something that works as-is so that
we don't need to patch it up. Btw: -frecursive is added in the build of
0.3.10, too. Not sure if it checks for old gcc versions that don't
support it, but I do think it is reasonable to suggest that people who
choose math/openblas also choose a fairly recent compiler.

Anyhow, seems like one needs to be careful not to jump to every new
version right away. I'm not happy about this, but this is a source of
issues to keep in mind: The highly optimized OpenBLAS interacts closely
with GCC versions and CPU instruction sets, it will probably always be
broken in some setups.

I'll push an update to 0.3.10 when I tested it here and maybe add a
note that one should wait for a version after 0.3.12 for the next
update. I prefer being conservative here to adding/dropping patches for
build regressions.

To get back on the topic: There's enough trouble getting Fortran
software to build properly at all. Then with mixed GCC/Fortran use, too
…

> 3) The aforementioned gfortran issues are in the way of committing 
> wip/cblas and wip/lapacke as well.  These two packages are not
> urgently needed as far as I can tell, so I think we might as well fix
> the global Fortran issues before committing them.

My patches make math/py-numpy use BLAS through cblas, but LAPACK
explicitly. I'd need to dig a bit in history to recall what the exact
reason is. Perhaps that it just _can_ use CBLAS, avoiding an internal
copy or accidental pick-up of a libcblas that we didn't intend.

Numpy is a major node in the software graph that I really would like to
get out of my patching zone. I'll also try to upstream support for
using BLAS_LIBS / LAPACK_LIBS, to be able to drop the fragile patch on
their system configure script in pkgsrc.

> 4) I think the CONFIGURE_ARGS issues are best tested and committed
> one package at a time, now that the BLAS infrastructure is in-place.

OK.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg