Tests hanging on OpenBSD

[epsilon-0]

OpenBLAS is building now but it still seems to not be able to run the full tests.

Make options

CFLAGS="-O2 -pipe" FFLAGS="-O2 -pipe" \
                FC="egfortran" CC="cc" \
                USE_THREAD=1 USE_OPENMP=0 \
                NUM_PARALLEL=8 \
                NUM_THREADS=64 \
                MAKE_NB_JOBS=-1 \
                DYNAMIC_ARCH=1 \
                TARGET=GENERIC \
                NO_AFFINITY=1 \
                NO_STATIC=0 \
                BUILD_RELAPACK=1

When gmake test

===>  Regression tests for openblas-0.3.12
touch libopenblasp-r0.3.12.dev.a
gmake -C test all
gmake[1]: Entering directory '/usr/obj/ports/openblas-0.3.12/OpenBLAS-aa21cb52179b86b00f7ac52a4e41ed712836f2d1/test'
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o sblat1 sblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o dblat1 dblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o cblat1 cblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o zblat1 zblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat1

The test now hangs here indefinitely.

My system variables used
Operating System - OpenBSD -current
CPU - 2x Intel Xeon E5-2630 v2 SR1AM Hex Core 2.6GHz LGA 2011 CPU Processor
CC - OpenBSD clang version 10.0.1
FC - GNU Fortran (GCC) 8.4.0

[martin-frbg]

Can you try without ReLAPACK please (still having problems building gcc8.4 on OpenBSD currently) ? I thought I had fixed all the infinite recursions in ReLAPACK with 0.3.11/0.3.12 but perhaps there is one there still.

[epsilon-0]

Thanks will do, but its gonna take quite a while.
The compilation on OpenBSD is slow (openbsd is slow in general).

[epsilon-0]

Also, you should be able to add gcc from ports using pkg_add instead of building it from scratch.

[martin-frbg]

Thanks, need to look into that (in particular if I can redirect the install to my home as the gccfarm setup is (or at least appears to me as)a nonpriviledged account on a shared machine, not a VM spawned exclusively for my task. May need to set up a local VM

[epsilon-0]

OK, so I ran them with BUILD_RELAPACK=0

CFLAGS="-O2 -pipe" FFLAGS="-O2 -pipe" \
                FC="egfortran" CC="cc" \
                USE_THREAD=1 USE_OPENMP=0 \
                NUM_PARALLEL=8 \
                NUM_THREADS=64 \
                MAKE_NB_JOBS=-1 \
                DYNAMIC_ARCH=1 \
                TARGET=GENERIC \
                NO_AFFINITY=1 \
                NO_STATIC=0 \
                BUILD_RELAPACK=0

They are still hanging

===>  Regression tests for openblas-0.3.12
touch libopenblasp-r0.3.12.dev.a
gmake -C test all
gmake[1]: Entering directory '/usr/obj/ports/openblas-0.3.12/OpenBLAS-aa21cb52179b86b00f7ac52a4e41ed712836f2d1/test'
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o sblat1 sblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o dblat1 dblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o cblat1 cblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o zblat1 zblat1.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o sblat2 sblat2.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o dblat2 dblat2.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o cblat2 cblat2.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o zblat2 zblat2.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o sblat3 sblat3.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o dblat3 dblat3.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o cblat3 cblat3.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
gfortran -O2 -pipe -Wall -frecursive -fno-optimize-sibling-calls -m64  -Wall -frecursive -fno-optimize-sibling-calls -m64   -o zblat3 zblat3.o ../libopenblasp-r0.3.12.dev.a -lpthread -lgfortran -lpthread -lgfortran -L/usr/bin/../lib -L/usr/lib  -lc
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat1
rm -f ?BLAT3.SUMM
rm -f ?BLAT2.SUMM
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat3 < ./sblat3.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < ./sblat2.dat

The three tests are still running, in parallel, so I had to Ctrl-C stop them.

[martin-frbg]

Reproduced, and first impression is that it is not actually hanging, but counting down an enormous loop variable. Suspect the TARGET=GENERIC in combination with DYNAMIC_ARCH may be creating an internal ABI mismatch where parts assume long doubles for extended precision support while others do not. (TARGET=GENERIC sets NO_EXPRECISION=1, which for Linux or non-x86 is the global default anyway). Case in point, TARGET=PRESCOTT DYNAMIC_ARCH=1 seems to work fine.

[epsilon-0]

Wow, nice find :O
I've no idea what a good solution might be for this?

[martin-frbg]

Not a nice find I think.. and this must have been lurking for years. (Only the suggestion used to be to use CORE2 or PRESCOTT as the least common denominator, if/when this was given any thought at all). I am not entirely sure if we want to enable EXPRECISION on BSD/x86 when it is disabled on Linux/x86 (and Windows too).

[martin-frbg]

#2966 adds that conditional, but I notice that CMAKE builds already disable EXPRECISION for the BSDs and derivatives. (Need to check why that is the case - if there was another problem or just a misdiagnosed previous occurence of this here bug)

[epsilon-0]

thanks, am giving it a whirl!

[brada4]

What works for me:
E5-2420 v2 vmware 6.7 EVC ivy bridge , VMX 13, Guest Type - FreeBSD, OpenBSD 6.8 amd64 installed.
gmake $GRA ; gmake $GRA test ; gmake clean
where GRA is:
CC=egcc FC=egfortran
CC=cc FC=egfortran
Not sure if it matters, but I religiously repeat build parameters for test.

Also when you say "test hangs" - does system work enough to kill test or attach a debugger? (That is I suspect NMI because of thermal throttiling or so)

[martin-frbg]

@brada4 test is a subtarget of the default all unless cross-compiling. And the "test hangs" have been reproduced and hopefully fixed already - see messages above.

[epsilon-0]

Hmm, that doesn't work. The tests are still stuck on the same place.