OpenBLAS: Tests hanging on OpenBSD

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

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 28 (19 by maintainers)

Most upvoted comments

@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.

martin-frbg on Nov 1, 2020

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.

martin-frbg on Nov 1, 2020