amax:samax utest failure #1912

virtuald · 2018-12-12T05:16:34Z

System configuration:

Compile host is ODROID-C2, but I'm running the compile inside of a docker image that was created from a NI RoboRIO disk image (ARMv7, Cortex A9). I'm also using setarch linux32.
Compilers are gcc 6.3.0, gfortran 6.3.0
OpenBLAS 0.3.4 (but the error occurs on 0.2.20 also)

Compile was via:

make TARGET=CORTEXA9 PREFIX=/usr/local

Here's the output:

./openblas_utest 
TEST 1/23 amax:samax [FAIL]
  ERR: test_amax.c:44  expected 3.300e+00, got 4.204e-45 (diff 3.300e+00, tol 1.000e-04)
...
RESULTS: 23 tests (22 ok, 1 failed, 0 skipped) ran in 1860 ms

What steps should I take next to diagnose this issue? Thanks!

The text was updated successfully, but these errors were encountered:

virtuald · 2018-12-12T05:31:05Z

Looking more at the compile log, this pops out at me:

OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat3 < ./sblat3.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./dblat3 < ./dblat3.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./cblat2 < ./cblat2.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./cblat3 < ./cblat3.dat
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./zblat2 < ./zblat2.dat
 TESTS OF THE COMPLEX          LEVEL 3 BLAS

 THE FOLLOWING PARAMETER VALUES WILL BE USED:
   FOR N                   0     1     2     3     7    31
   FOR ALPHA          ( 0.0, 0.0)  ( 1.0, 0.0)  ( 0.7,-0.9)  
   FOR BETA           ( 0.0, 0.0)  ( 1.0, 0.0)  ( 1.3,-1.1)  

 ERROR-EXITS WILL NOT BE TESTED

 ROUTINES PASS COMPUTATIONAL TESTS IF TEST RATIO IS LESS THAN   16.00

 RELATIVE MACHINE PRECISION IS TAKEN TO BE  1.2E-07

 CGEMM  PASSED THE COMPUTATIONAL TESTS ( 17496 CALLS)

 CHEMM  PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CSYMM  PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CTRMM  PASSED THE COMPUTATIONAL TESTS (  2592 CALLS)

 CTRSM  PASSED THE COMPUTATIONAL TESTS (  2592 CALLS)

 ******* FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF ACCURATE *******
                       EXPECTED RESULT                    COMPUTED RESULT
       1  (  -0.153378    ,    0.00000    )  (  -0.153378    ,    0.00000    )
       2  (   0.714370    ,   0.406021    )  (   0.714370    ,   0.406021    )
       3  (   0.209727    ,   0.325695    )  (   0.969031E-01,   0.298701    )
      THESE ARE THE RESULTS FOR COLUMN   1
 ******* CHERK  FAILED ON CALL NUMBER:
    698: CHERK ('L','N',  3,  1, 1.0, A,  4, 1.0, C,  4)                         .

 CSYRK  PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CHER2K PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CSYR2K PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 END OF TESTS
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./zblat3 < ./zblat3.dat
rm -f ?BLAT3.SUMM
OPENBLAS_NUM_THREADS=2 ./sblat3 < ./sblat3.dat
rm -f ?BLAT2.SUMM
OPENBLAS_NUM_THREADS=2 ./sblat2 < ./sblat2.dat
OPENBLAS_NUM_THREADS=2 ./dblat3 < ./dblat3.dat
OPENBLAS_NUM_THREADS=2 ./dblat2 < ./dblat2.dat
OPENBLAS_NUM_THREADS=2 ./cblat3 < ./cblat3.dat
OPENBLAS_NUM_THREADS=2 ./cblat2 < ./cblat2.dat
 TESTS OF THE COMPLEX          LEVEL 3 BLAS

 THE FOLLOWING PARAMETER VALUES WILL BE USED:
   FOR N                   0     1     2     3     7    31
   FOR ALPHA          ( 0.0, 0.0)  ( 1.0, 0.0)  ( 0.7,-0.9)  
   FOR BETA           ( 0.0, 0.0)  ( 1.0, 0.0)  ( 1.3,-1.1)  

 ERROR-EXITS WILL NOT BE TESTED

 ROUTINES PASS COMPUTATIONAL TESTS IF TEST RATIO IS LESS THAN   16.00

 RELATIVE MACHINE PRECISION IS TAKEN TO BE  1.2E-07

 CGEMM  PASSED THE COMPUTATIONAL TESTS ( 17496 CALLS)

 CHEMM  PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CSYMM  PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CTRMM  PASSED THE COMPUTATIONAL TESTS (  2592 CALLS)

 CTRSM  PASSED THE COMPUTATIONAL TESTS (  2592 CALLS)

 ******* FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF ACCURATE *******
                       EXPECTED RESULT                    COMPUTED RESULT
       1  (  -0.153378    ,    0.00000    )  (  -0.153378    ,    0.00000    )
       2  (   0.714370    ,   0.406021    )  (   0.714370    ,   0.406021    )
       3  (   0.209727    ,   0.325695    )  (   0.969031E-01,   0.298701    )
      THESE ARE THE RESULTS FOR COLUMN   1
 ******* CHERK  FAILED ON CALL NUMBER:
    698: CHERK ('L','N',  3,  1, 1.0, A,  4, 1.0, C,  4)                         .

 CSYRK  PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CHER2K PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 CSYR2K PASSED THE COMPUTATIONAL TESTS (  1296 CALLS)

 END OF TESTS
OPENBLAS_NUM_THREADS=2 ./zblat3 < ./zblat3.dat
OPENBLAS_NUM_THREADS=2 ./zblat2 < ./zblat2.dat
make[1]: Leaving directory '/home/admin/v0.3.4/test'

martin-frbg · 2018-12-12T06:59:32Z

Interesting, I did not see these failures on Cortex A17 and the samax microkernel was last touched in #740 (apart from a trivial instruction change a few months ago, but that happened after the 0.2.20 release that you say is also affected).
Is CHERK the only test failure with that dreaded old "less than half accurate" message?

martin-frbg · 2018-12-12T07:31:34Z

A quick workaround for the SAMAX issue would be to append

SAMAXKERNEL = amax.c
DAMAXKERNEL = amax.c
CAMAXKERNEL = zamax.c
ZAMAXKERNEL = zamax.c

in kernel/arm/KERNEL.CORTEXA9. (Not entirely sure if this would address the CHERK problem as well, but probably not. )

brada4 · 2018-12-12T07:32:31Z

Could you post longer, like full build log?
Is arm64 working correctly with your CPU?

virtuald · 2018-12-12T07:50:15Z

Here's the full logfile: openblas_log.txt

brada4 · 2018-12-12T11:37:36Z

No incidents during build.

virtuald · 2018-12-13T05:31:28Z

Modified the kernel file, did a build, still failed. Doing a make clean followed by a build... seems the CHERK tests are still failing:

 ******* FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF ACCURATE *******
                       EXPECTED RESULT                    COMPUTED RESULT
       1  (  -0.153378    ,    0.00000    )  (  -0.153378    ,    0.00000    )
       2  (   0.714370    ,   0.406021    )  (   0.714370    ,   0.406021    )
       3  (   0.209727    ,   0.325695    )  (   0.969031E-01,   0.298701    )
      THESE ARE THE RESULTS FOR COLUMN   1
 ******* CHERK  FAILED ON CALL NUMBER:
    698: CHERK ('L','N',  3,  1, 1.0, A,  4, 1.0, C,  4)

However, running a new utest seems to have fixed that issue.

By checking arm64, I assume you mean building on the ODROID host outside of the docker image?

brada4 · 2018-12-13T09:08:31Z

Your CPU is a 64bit A53, and will work faster with 64bit build on a 64bit OS (though it is important here to have last avail 32bit option to work fine too)

martin-frbg · 2018-12-13T12:10:50Z

CHERK codepath involves syrk/gemm but the individual tests for those appear to pass (as does the ZHERK test). I will try to do a TARGET=CORTEXA9 build on my A17 if and when I have time. (I do wonder if this could be a compiler problem though)

virtuald · 2018-12-13T13:48:49Z

@brada4 the target ARM system that I'll be running the compiled OpenBLAS on is a A9, so this is vaguely a cross compile. It's just the ODROID is way faster at compiling things, so I'd rather use that to compile. :)

@martin-frbg totally could be a compiler thing seeing as I had to build the fortran compiler package myself via bitbake... any thoughts on how I can detect that?

martin-frbg · 2018-12-13T21:14:18Z

No idea except perhaps trying another compiler build or version. Unmodified "develop" branch passes all tests on my Cortex A17 (Asus Tinkerboard, gcc 6.3.0) with TARGET=CORTEXA9 (which btw appears to be pretty much identical to the ARMV7 target that gets built by default)

brada4 · 2018-12-13T21:17:54Z

Can you try TARGET=ARMV5 which is pure C before implicating your gfortran? It is quite unlikely that dozen tests were OK with same gfortran, then one choked.

virtuald · 2018-12-14T05:50:23Z

Tried TARGET=ARMV5, but the tests segfaulted. ldd says it was linked to libgfortran, so I restarted the docker image and did not install gfortran et al in it. Once I did that, it built without any issues, but there doesn't seem to be any tests?

brada4 · 2018-12-14T08:53:44Z

Tests are compiled with fortran compiler, so in absence of such they dont compile.
You have to run "make clean" between build parameter changes, there should be no difference in interface where fortran links to.

Haffon · 2019-05-22T16:26:17Z

I have the same issue, and the failed number is just same with virtuald. I'm compiling OpenBLAS 0.3.6 for
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 72.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae

martin-frbg · 2019-05-22T17:43:38Z

@Haffon are you (cross)compiling this on a 64bit processor in 32bit mode (like virtuald did), or how/where do you compile ?

Haffon · 2019-05-23T00:22:40Z

＠martin-frbg I‘m not cross compiling. I just download the 0.3.6 code into the arm board and type make. I have done the workaround with the SAMAX in kernel/arm/KERNEL.CORTEXA9 and the error still exist. I can ssh to that board and the board have HDMI and usb ports, so it can by used as a standalone like PC. An debian based OS has been installed in this board.
uname -a
Linux linbian 4.4.55+ #1 SMP PREEMPT Thu Jan 31 19:03:50 PST 2019 armv7l GNU/Linux
I even can use sudo apt-get install libsnappy-dev to install packages.

brada4 · 2019-05-23T06:27:59Z

ARMv7 is 32bit, I do not know what is that linux32. Probably no forced arch or target since whole build is on the host.

martin-frbg · 2019-05-23T06:31:32Z

Interesting, so same as with my arm board (Asus Tinkerboard) where I did not see these failures.

Haffon · 2019-05-23T08:51:30Z

since there is no installation instruction for arm-linux, so I just type make and enter. The Android section is tell me to do cross compile without Fortran, they are not my case. I changed the compile command to
make TARGET=ARMV7
to make tools think they are cross compiling. Does they work for me, and what make install do if it is in cross compile?

martin-frbg · 2019-05-23T09:11:19Z

Both just "make" and "make TARGET=ARMV7" should work (without the TARGET argument it would autodetect the cpu, which should result in ARMV7 as well - nothing to do with cross-compile). My Tinkerboard identifies as ARMv7 rev 1 (v7l) with additional cpu features "thumbee" and "evtstrm" that probably play no role here. gcc default target (from gcc -v) is arm-linux-gnueabihf, maybe that is the difference ?

Haffon · 2019-05-23T09:34:18Z

my "gcc -v" show the "--target=arm-linux-gnueabi", "cat /proc/cpuinfo" has no "thumbee" and "evtstrm" feature. use "make TARGET=ARMV7" doesn't work, I finally using "make NOFORTRAN=1" and the compilation is done, hope it will work in my application since there is no utest.

martin-frbg · 2019-05-23T09:47:23Z

Alright. So the SAMAX problem seems to be specific to "softfp" builds (while my Tinkerboard is set up for hardfp so I cannot reproduce the bug there - I need to find out if I need to (and can) install another gcc toolchain to change this).
With NOFORTRAN=1 it will not build the BLAS and LAPACK tests as these are written in fortran, not sure why it would not build and run the utests.
EDIT: seems to be a small bug in the Makefile logic - you can run "make" in the utest directory after
building the library to get the utests.

Haffon · 2019-05-23T09:58:34Z

Some body told me to use this branch "https://github.com/xianyi/OpenBLAS/tree/arm_soft_fp_abi", but still not work as "gnu/stubs-hard.h: No such file or directory".
In fact I'm porting caffe to some kind for development board which has arm core, I can't do "sudo apt-get install libopenblas-dev" described in "https://github.com/OAID/Caffe-HRT/blob/master/acl_openailab/installation.md", so I try to compile it manually.
Thanks.

brada4 · 2019-05-23T10:04:05Z

That is 2 years untouched development branch. Probably you need to add universe or something like that. Packages are alive and well:
https://packages.debian.org/stretch/libopenblas-base
https://packages.ubuntu.com/disco/armhf/libopenblas-dev

martin-frbg · 2019-05-23T10:13:28Z

The soft_fp_abi branch is from the first attempts to support softfp two years ago, only a few functions in it were modified back then - but it looks as if iamax_vfp.S and possibly other files are still not modified for softfp in the current version. (From looking at sdot_vfp.S, the change could be as simple as moving the computed result to a different register before returning)

Haffon · 2019-05-23T14:13:01Z

@brada4 It is good way to download the .deb, but the site list of "https://packages.ubuntu.com/disco/armhf/libopenblas-dev/download" is blank.
Debian package is downloadable "https://packages.debian.org/stretch/armhf/libopenblas-base/download" except the version is 0.2.19.

Haffon · 2019-05-23T16:40:23Z

The debian architecture should be armel, but only armhf downloading url is present for libopenblas-base.
After I run "readelf -A /proc/self/exe | grep Tag_ABI_VFP_args" nothing return, and "make TARGET_ARCH=armel" failed with "cc: error: armel: No such file or directory" when making utest.

brada4 · 2019-05-23T20:08:13Z

armel is fpu-less calling convention
TARGET=ARMv5 will use no assembly, thus be indifferent from calling convention. Try that.

martin-frbg · 2019-05-23T21:30:13Z

Hmm. I downloaded the Linbian sd image in the hope of running it from qemu, but I cannot find a kernel or initrd in it (/boot appears to be empty, but I see kernel modules under lib/modules/4.4.55+) Does this use some nonconventional boot process, or is there something wrong with the "eagle-debian-lindeni-v5-flat" image of 2019-02-01?

brada4 · 2019-05-29T10:14:37Z

I think best choice at present is TARGET=ARMv5, there is anticipated missing performance, but at least it works.

ashwinyes · 2019-05-29T10:30:34Z

Few things to note.

Regarding amax.

Using iamax_vfp.S for amax kernel is wrong. iamax_vfp.S only has the implementation to find the index of the max value. So KERNEL.ARMV6 needs to be corrected. This looks to be long standing undetected issue in OpenBLAS.
For the same reason, Add softfp support in min/max kernels #2142 is not correct. Needs to be reverted. This will break isamax .
The current implementation in iamax_vfp.S works for hardfp for samax because inadvertently it stores the max value in s0 where it is supposed to end up.

Regarding CHERK

Looks to be a compiler/environment issue. Could you try replacing -O2 by -O0 in Makefile.system for FCOMMON_OPT and COMMON_OPT
Also try setting "ulimit -s unlimited"

Haffon · 2019-05-29T10:46:12Z

@ashwinyes I will do it described in "Regarding CHERK" after package installation is done.

Haffon · 2019-05-29T12:19:04Z

The "cblas_cherk" error disappear after I replace -O2 by -O0 and unlimite the stack size.

ashwinyes · 2019-05-29T12:40:48Z

Thanks. Would you be able to narrow it down as to which one actually helps ?

Haffon · 2019-05-29T14:12:35Z

@ashwinyes The cblas_cherk error appear if I turn the optimize on(-O2).

ashwinyes · 2019-05-30T05:40:44Z

@Haffon Looks to be a compiler issue. Would it be possible to change the compiler and re-test ?

brada4 · 2019-05-30T07:36:46Z

gcc 6.3.0 is part of Ubuntu zesty, long EOL, so compiler problems are essentially unfixable if found.
You need to move to LTS (e.g. 18.04) to get it working.
e.g. https://wiki.odroid.com/odroid-c2/os_images/ubuntu/ubuntu
Probably nobody tried setarch, so maybe try clean(-er) cross-build (Your build host is aarch64, target is softfp):
make CC=arm-????-gcc HOSTCC=cc FC=arm-????-gfortran TARGET=ARMv7

ashwinyes · 2019-05-30T07:50:28Z

In ubuntu, you may use use update-alternatives to switch between different compiler version if they are available.

For a start see, https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version

Haffon · 2019-05-30T10:10:50Z

@brada4 @ashwinyes Thanks, my gcc version is
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
The OS I'm using is "linbian", I think it is more same with Debian, and the last gcc for Debian is 6.3.0. I will try to update-alternatives to narrow down the issue.

martin-frbg · 2019-05-30T11:16:40Z

@brada4 the Odroid board was what the original issue was about, this here seems to be a Lindenis V5 setup with a genuine 32bit cpu.

brada4 · 2019-05-30T18:27:13Z

The initial issue is ubuntu (it turns out debian9?) on an odroid is used to build for roborio target. It fails on that build platform, though should not.

martin-frbg · 2019-05-30T18:37:57Z

@brada4 well yes, but the Odroid guy is a different person than the one who revived this issue, and has not taken part in this since december.

brada4 · 2019-05-30T18:45:20Z

Ouch, my bad. I think ARMV5 gets project ahead while this project is at digging ARMv7 softfp dilemma. :-S

Haffon · 2019-05-31T01:18:05Z

Since there is no easy way to alter the gcc version, I need more time to narrow down.

virtuald · 2019-05-31T01:30:24Z

Hi, roborio guy here. I'm still interested in this, but don't really have time to fix/test anything at the present moment (and robotics stuff is more of a winter thing for me anyways). Hoping that this will be fixed by next season! :)

* With the Intel compiler on Linux, prefer ifort for the final link step icc has known problems with mixed-language builds that ifort can handle just fine. Fixes OpenMathLib#1956 * Rename operands to put lda on the input/output constraint list * Fix wrong constraints in inline assembly for OpenMathLib#2009 * Fix inline assembly constraints rework indices to allow marking argument lda4 as input and output. For OpenMathLib#2009 * Fix inline assembly constraints rework indices to allow marking argument lda as input and output. * Fix inline assembly constraints * Fix inline assembly constraints * Fix inline assembly constraints in Bulldozer TRSM kernels rework indices to allow marking i,as and bs as both input and output (marked operand n1 as well for simplicity). For OpenMathLib#2009 * Correct range_n limiting same bug as seen in OpenMathLib#1388, somehow missed in corresponding PR OpenMathLib#1389 * Allow multithreading TRMV again revert workaround introduced for issue OpenMathLib#1332 as the actual cause appears to be my incorrect fix from OpenMathLib#1262 (see OpenMathLib#1388) * Fix error introduced during cleanup * Reduce list of kernels in the dynamic arch build to make compilation complete reliably within the 1h limit again * init * move fix to right place * Fix missing -c option in AVX512 test * Fix AVX512 test always returning false due to missing compiler option * Make x86_32 imply NO_AVX2, NO_AVX512 in addition to NO_AVX fixes OpenMathLib#2033 * Keep xcode8.3 for osx BINARY=32 build as xcode10 deprecated i386 * Make sure that AVX512 is disabled in 32bit builds for OpenMathLib#2033 * Improve handling of NO_STATIC and NO_SHARED to avoid surprises from defining either as zero. Fixes OpenMathLib#2035 by addressing some concerns from OpenMathLib#1422 * init * address warning introed with OpenMathLib#1814 et al * Restore locking optimizations for OpenMP case restore another accidentally dropped part of OpenMathLib#1468 that was missed in OpenMathLib#2004 to address performance regression reported in OpenMathLib#1461 * HiSilicon tsv110 CPUs optimization branch add HiSilicon tsv110 CPUs optimization branch * add TARGET support for HiSilicon tsv110 CPUs * add TARGET support for HiSilicon tsv110 CPUs * add TARGET support for HiSilicon tsv110 CPUs * Fix module definition conflicts between LAPACK and ReLAPACK for OpenMathLib#2043 * 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 * ctest.c : add __POWERPC__ for PowerMac * Fix crash in sgemm SSE/nano kernel on x86_64 Fix bug OpenMathLib#2047. Signed-off-by: Celelibi <celelibi@gmail.com> * param.h : enable defines for PPC970 on DarwinOS fixes: gemm.c: In function 'sgemm_': ../common_param.h:981:18: error: 'SGEMM_DEFAULT_P' undeclared (first use in this function) #define SGEMM_P SGEMM_DEFAULT_P ^ * common_power.h: force DCBT_ARG 0 on PPC970 Darwin without this, we see ../kernel/power/gemv_n.S:427:Parameter syntax error and many more similar entries that relates to this assembly command dcbt 8, r24, r18 this change makes the DCBT_ARG = 0 and openblas builds through to completion on PowerMac 970 Tests pass * Make TARGET=GENERIC compatible with DYNAMIC_ARCH=1 for issue OpenMathLib#2048 * make DYNAMIC_ARCH=1 package work on TSV110. * make DYNAMIC_ARCH=1 package work on TSV110 * Add Intel Denverton for OpenMathLib#2048 * Add Intel Denverton * Change 64-bit detection as explained in OpenMathLib#2056 * Trivial typo fix as suggested in OpenMathLib#2022 * Disable the AVX512 DGEMM kernel (again) Due to as yet unresolved errors seen in OpenMathLib#1955 and OpenMathLib#2029 * Use POSIX getenv on Cygwin The Windows-native GetEnvironmentVariable cannot be relied on, as Cygwin does not always copy environment variables set through Cygwin to the Windows environment block, particularly after fork(). * Fix for OpenMathLib#2063: The DllMain used in Cygwin did not run the thread memory pool cleanup upon THREAD_DETACH which is needed when compiled with USE_TLS=1. * Also call CloseHandle on each thread, as well as on the event so as to not leak thread handles. * AIX asm syntax changes needed for shared object creation * power9 makefile. dgemm based on power8 kernel with following changes : 32x unrolled 16x4 kernel and 8x4 kernel using (lxv stxv butterfly rank1 update). improvement from 17 to 22-23gflops. dtrmm cases were added into dgemm itself * Expose CBLAS interfaces for I?MIN and I?MAX * Build CBLAS interfaces for I?MIN and I?MAX * Add declarations for ?sum and cblas_?sum * Add interface for ?sum (derived from ?asum) * Add ?sum * Add implementations of ssum/dsum and csum/zsum as trivial copies of asum/zsasum with the fabs calls replaced by fmov to preserve code structure * Add ARM implementations of ?sum (trivial copies of the respective ?asum with the fabs calls removed) * Add ARM64 implementations of ?sum as trivial copies of the respective ?asum kernels with the fabs calls removed * Add ia64 implementation of ?sum as trivial copy of asum with the fabs calls removed * Add MIPS implementation of ?sum as trivial copy of ?asum with the fabs calls removed * Add MIPS64 implementation of ?sum as trivial copy of ?asum with the fabs replaced by mov to preserve code structure * Add POWER implementation of ?sum as trivial copy of ?asum with the fabs replaced by fmr to preserve code structure * Add SPARC implementation of ?sum as trivial copy of ?asum with the fabs replaced by fmov to preserve code structure * Add x86 implementation of ?sum as trivial copy of ?asum with the fabs calls removed * Add x86_64 implementation of ?sum as trivial copy of ?asum with the fabs calls removed * Add ZARCH implementation of ?sum as trivial copies of the respective ?asum kernels with the ABS and vflpsb calls removed * Detect 32bit environment on 64bit ARM hardware for OpenMathLib#2056, using same approach as OpenMathLib#2058 * Add cmake defaults for ?sum kernels * Add ?sum * Add ?sum definitions for generic kernel * Add declarations for ?sum * Add -lm and disable EXPRECISION support on *BSD fixes OpenMathLib#2075 * Add in runtime CPU detection for POWER. * snprintf define consolidated to common.h * Support INTERFACE64=1 * Add support for INTERFACE64 and fix XERBLA calls 1. Replaced all instances of "int" with "blasint" 2. Added string length as "hidden" third parameter in calls to fortran XERBLA * Correct length of name string in xerbla call * Avoid out-of-bounds accesses in LAPACK EIG tests see Reference-LAPACK/lapack#333 * Correct INFO=4 condition * Disable reallocation of work array in xSYTRF as it appears to cause memory management problems (seen in the LAPACK tests) * Disable repeated recursion on Ab_BR in ReLAPACK xGBTRF due to crashes in LAPACK tests * sgemm/strmm * Update Changelog with changes from 0.3.6 * Increment version to 0.3.7.dev * Increment version to 0.3.7.dev * Misc. typo fixes Found via `codespell -q 3 -w -L ith,als,dum,nd,amin,nto,wis,ba -S ./relapack,./kernel,./lapack-netlib` * Correct argument of CPU_ISSET for glibc <2.5 fixes OpenMathLib#2104 * conflict resolve * Revert reference/ fixes * Revert Changelog.txt typos * Disable the SkyLakeX DGEMMITCOPY kernel as well as a stopgap measure for numpy/numpy#13401 as mentioned in OpenMathLib#1955 * Disable DGEMMINCOPY as well for now OpenMathLib#1955 * init * Fix errors in cpu enumeration with glibc 2.6 for OpenMathLib#2114 * Change two http links to https Closes OpenMathLib#2109 * remove redundant code OpenMathLib#2113 * Set up CI with Azure Pipelines [skip ci] * TST: add native POWER8 to CI * add native POWER8 testing to Travis CI matrix with ppc64le os entry * Update link to IBM MASS library, update cpu support status * first try migrating one of the arm builds from travis * fix tabbing in azure commands * Update azure-pipelines.yml take out offending lines (although stolen from https://github.com/conda-forge/opencv-feedstock azure-pipelines fiie) * Update azure-pipelines.yml * Update azure-pipelines.yml * Update azure-pipelines.yml * Update azure-pipelines.yml * DOC: Add Azure CI status badge * Add ARMV6 build to azure CI setup (OpenMathLib#2122) using aytekinar's Alpine image and docker script from the Travis setup [skip ci] * TST: Azure manylinux1 & clean-up * remove some of the steps & comments from the original Azure yml template * modify the trigger section to use develop since OpenBLAS primarily uses this branch; use the same batching behavior as downstream projects NumPy/ SciPy * remove Travis emulated ARMv6 gcc build because this now happens in Azure * use documented Ubuntu vmImage name for Azure and add in a manylinux1 test run to the matrix [skip appveyor] * Add NO_AFFINITY to available options on Linux, and set it to ON to match the gmake default. Fixes second part of OpenMathLib#2114 * Replace ISMIN and ISAMIN kernels on all x86_64 platforms (OpenMathLib#2125) * Mark iamax_sse.S as unsuitable for MIN due to issue OpenMathLib#2116 * Use iamax.S rather than iamax_sse.S for ISMIN/ISAMIN on all x86_64 as workaround for OpenMathLib#2116 * Move ARMv8 gcc build from Travis to Azure * Move ARMv8 gcc build from Travis to Azure * Update .travis.yml * Test drone CI * install make * remove sudo * Install gcc * Install perl * Install gfortran and add a clang job * gfortran->gcc-gfortran * Switch to ubuntu and parallel jobs * apt update * Fix typo * update yes * no need of gcc in clang build * Add a cmake build as well * Add cmake builds and print options * build without lapack on cmake * parallel build * See if ubuntu 19.04 fixes the ICE * Remove qemu armv8 builds * arm32 build * Fix typo * TST: add SkylakeX AVX512 CI test * adapt the C-level reproducer code for some recent SkylakeX AVX512 kernel issues, provided by Isuru Fernando and modified by Martin Kroeker, for usage in the utest suite * add an Intel SDE SkylakeX emulation utest run to the Azure CI matrix; a custom Docker build was required because Ubuntu image provided by Azure does not support AVX512VL instructions * Add option USE_LOCKING for single-threaded build with locking support for calling from concurrent threads * Add option USE_LOCKING for single-threaded build with locking support * Add option USE_LOCKING for SMP-like locking in USE_THREAD=0 builds * Add option USE_LOCKING but keep default settings intact * Remove unrelated change * Do not try ancient PGI hacks with recent versions of that compiler should fix OpenMathLib#2139 * Build and run utests in any case, they do their own checks for fortran availability * Add softfp support in min/max kernels fix for OpenMathLib#1912 * Revert "Add softfp support in min/max kernels" * Separate implementations of AMAX and IAMAX on arm As noted in OpenMathLib#1912 and comment on OpenMathLib#1942, the combined implementation happens to "do the right thing" on hardfp, but cannot return both value and index on softfp where they would have to share the return register * Ensure correct output for DAMAX with softfp * Use generic kernels for complex (I)AMAX to support softfp * improved zgemm power9 based on power8 * upload thread safety test folder * hook up c++ thread safety test (main Makefile) * add c++ thread test option to Makefile.rule * Document NO_AVX512 for OpenMathLib#2151 * sgemm pipeline improved, zgemm rewritten without inner packs, ABI lxvx v20 fixed with vs52 * Fix detection of AVX512 capable compilers in getarch 21eda8b introduced a check in getarch.c to test if the compiler is capable of AVX512. This check currently fails, since the used __AVX2__ macro is only defined if getarch itself was compiled with AVX2/AVX512 support. Make sure this is the case by building getarch with -march=native on x86_64. It is only supposed to run on the build host anyway. * c_check: Unlink correct file * power9 zgemm ztrmm optimized * conflict resolve * Add gfortran workaround for ABI violations in LAPACKE for OpenMathLib#2154 (see gcc bug 90329) * Add gfortran workaround for ABI violations for OpenMathLib#2154 (see gcc bug 90329) * Add gfortran workaround for potential ABI violation for OpenMathLib#2154 * Update fc.cmake * Remove any inadvertent use of -march=native from DYNAMIC_ARCH builds from OpenMathLib#2143, -march=native precludes use of more specific options like -march=skylake-avx512 in individual kernels, and defeats the purpose of dynamic arch anyway. * Avoid unintentional activation of TLS code via USE_TLS=0 fixes OpenMathLib#2149 * Do not force gcc options on non-gcc compilers fixes compile failure with pgi 18.10 as reported on OpenBLAS-users * Update Makefile.x86_64 * Zero ecx with a mov instruction PGI assembler does not like the initialization in the constraints. * Fix mov syntax * new sgemm 8x16 * Update dtrmm_kernel_16x4_power8.S * PGI compiler does not like -march=native * Fix build on FreeBSD/powerpc64. Signed-off-by: Piotr Kubaj <pkubaj@anongoth.pl> * Fix build for PPC970 on FreeBSD pt. 1 FreeBSD needs DCBT_ARG=0 as well. * Fix build for PPC970 on FreeBSD pt.2 FreeBSD needs those macros too. * cgemm/ctrmm power9 * Utest needs CBLAS but not necessarily FORTRAN * Add mingw builds to Appveyor config * Add getarch flags to disable AVX on x86 (and other small fixes to match Makefile behaviour) * Make disabling DYNAMIC_ARCH on unsupported systems work needs to be unset in the cache for the change to have any effect * Mingw32 needs leading underscore on object names (also copy BUNDERSCORE settings for FORTRAN from the corresponding Makefile)

LydiaZhang2017 · 2019-07-23T12:14:36Z

Hi, I met similar issue and could anyone help to confirm if this is an issue on Openblas ?
cross compile with gcc-7.3.0 to build Openblas-0.3.6

Build passed with compile command:
make TARGET=POWER8 HOSTCC=gcc CC=xxxx FC=xxxx ......

Build failed with compile command:
make TARGET_ARCH=ppc64le TARGET=POWER8 HOSTCC=gcc CC=xxxx FC=xxxx .....

Output for failure:

make -j 8 -C utest all
.......
-mcpu=power8 -mtune=power8 -mvsx -malign-power -DUSE_OPENMP -fno-fast-math -fopenmp -DUTEST_CHECK -DSANITY_CHECK -DREFNAME=utest_mainf_ -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=8 -DMAX_PARALLEL_NUMBER=1 -DVERSION="0.3.6" -DASMNAME=utest_main -DASMFNAME=utest_main_ -DNAME=utest_main_ -DCNAME=utest_main -DCHAR_NAME="utest_main_" -DCHAR_CNAME="utest_main" -DNO_AFFINITY -I.. ppc64le -c -o utest_main.o utest_main.c
powerpc64le-unknown-linux-gnu-gcc: error: ppc64le: No such file or directory
: recipe for target 'utest_main.o' failed
make[1]: *** [utest_main.o] Error 1

Any value of TARGET_ARCH will always pass to utest and make build fail.
Can't we pass "TARGET_ARCH" to Openblas ?
Thanks.

martin-frbg · 2019-07-23T13:49:22Z

@LydiaZhang2017 I do not see how your problem is related to this (ARM gcc) issue at all, except that you happened to cross-compile ? Nothing in the OpenBLAS build system uses TARGET_ARCH, but as it is a built-in function of make it adds the output of uname -p to the command line, confusing the compiler.

LydiaZhang2017 · 2019-07-24T12:48:38Z

Thanks for verification and opening new issue for this.
I updated it here because it's similar to comment in this issue.
I will follow #2193.

brada4 · 2019-07-24T12:50:39Z

Its a PR, i.e attempt to fix. If you could verify if it works after change

LydiaZhang2017 · 2019-07-24T12:57:04Z

Its a PR, i.e attempt to fix. If you could verify if it works after change

Please note this also exist in ctest.
After adding "override TARGET_ARCH=" in Makefile of utest and ctest, build passed.

martin-frbg · 2019-07-24T13:18:56Z

Thanks for the feedback (must have totally missed - or forgotten about - the TARGET_ARCH reference in the earlier comment, sorry). I had only looked at test and lapack test, will update the PR to fix the ctest Makefile as well.

Haffon · 2019-08-08T15:02:34Z

I have downloaded the gcc 9.1.0 source and compile it, then I compile new download develop branch source of OpenBLAS with
make CC=/home/ai/opt/gcc-9.1.0/bin/armv7l-unknown-linux-gnueabi-gcc FC=/home/ai/opt/gcc-9.1.0/bin/armv7l-unknown-linux-gnueabi-gfortran HOSTCC=gcc
the amax:samax issue has gone, but there is still 2 "FATAL ERROR" issues. I will report after changing the -O option in Makefile.system.

Haffon · 2019-08-08T16:34:22Z

test pass with -O1, I will use OpenBLAS compiled with this option in my armv7l platform. Is there any hints in "https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html"?

martin-frbg · 2019-08-08T17:36:10Z

Thanks. No obvious hint (at least for me) in the list of options that get added at -O2, in particular as we cannot be sure which file it is that gets miscompiled at that level. I guess the most likely one
is the cgemm assembly kernel as it seems all other microkernels used for/by CHERK are written
in C - so only the cgemm_kernel_2x2_vfpv3.S has special code for softfp in it.
Perhaps you could try leaving the -O2 in Makefile.system, and overriding it only in kernel/Makefile
or specifically kernel/Makefile.L3 - something like override CFLAGS=$subst(-O2,-O1,$(CFLAGS))

virtuald · 2019-12-20T14:27:16Z

I've gotten it to compile this year (with gcc 7.3.0 and OpenBLAS 0.3.7). Thanks!

martin-frbg mentioned this issue May 29, 2019

Separate implementations of AMAX and IAMAX on arm #2145

Merged

martin-frbg mentioned this issue Jul 23, 2019

Override special make variables #2193

Merged

virtuald closed this as completed Dec 20, 2019

amax:samax utest failure #1912

amax:samax utest failure #1912

Comments

virtuald commented Dec 12, 2018 • edited Loading

virtuald commented Dec 12, 2018

martin-frbg commented Dec 12, 2018

martin-frbg commented Dec 12, 2018

brada4 commented Dec 12, 2018

virtuald commented Dec 12, 2018

brada4 commented Dec 12, 2018

virtuald commented Dec 13, 2018

brada4 commented Dec 13, 2018 • edited Loading

martin-frbg commented Dec 13, 2018

virtuald commented Dec 13, 2018 • edited Loading

martin-frbg commented Dec 13, 2018

brada4 commented Dec 13, 2018

virtuald commented Dec 14, 2018 • edited Loading

brada4 commented Dec 14, 2018

Haffon commented May 22, 2019

martin-frbg commented May 22, 2019

Haffon commented May 23, 2019 • edited Loading

brada4 commented May 23, 2019

martin-frbg commented May 23, 2019

Haffon commented May 23, 2019 • edited Loading

martin-frbg commented May 23, 2019

Haffon commented May 23, 2019

martin-frbg commented May 23, 2019 • edited Loading

Haffon commented May 23, 2019

brada4 commented May 23, 2019

martin-frbg commented May 23, 2019

Haffon commented May 23, 2019 • edited Loading

Haffon commented May 23, 2019 • edited Loading

brada4 commented May 23, 2019

martin-frbg commented May 23, 2019

brada4 commented May 29, 2019

ashwinyes commented May 29, 2019 • edited Loading

Haffon commented May 29, 2019

Haffon commented May 29, 2019

ashwinyes commented May 29, 2019

Haffon commented May 29, 2019

ashwinyes commented May 30, 2019

brada4 commented May 30, 2019 • edited Loading

ashwinyes commented May 30, 2019

Haffon commented May 30, 2019

martin-frbg commented May 30, 2019

brada4 commented May 30, 2019

martin-frbg commented May 30, 2019

brada4 commented May 30, 2019

Haffon commented May 31, 2019

virtuald commented May 31, 2019

LydiaZhang2017 commented Jul 23, 2019 • edited Loading

martin-frbg commented Jul 23, 2019

LydiaZhang2017 commented Jul 24, 2019

brada4 commented Jul 24, 2019

LydiaZhang2017 commented Jul 24, 2019

martin-frbg commented Jul 24, 2019

Haffon commented Aug 8, 2019 • edited Loading

Haffon commented Aug 8, 2019

martin-frbg commented Aug 8, 2019

virtuald commented Dec 20, 2019

virtuald commented Dec 12, 2018 •

edited

Loading

brada4 commented Dec 13, 2018 •

edited

Loading

virtuald commented Dec 13, 2018 •

edited

Loading

virtuald commented Dec 14, 2018 •

edited

Loading

Haffon commented May 23, 2019 •

edited

Loading

Haffon commented May 23, 2019 •

edited

Loading

martin-frbg commented May 23, 2019 •

edited

Loading

Haffon commented May 23, 2019 •

edited

Loading

Haffon commented May 23, 2019 •

edited

Loading

ashwinyes commented May 29, 2019 •

edited

Loading

brada4 commented May 30, 2019 •

edited

Loading

LydiaZhang2017 commented Jul 23, 2019 •

edited

Loading

Haffon commented Aug 8, 2019 •

edited

Loading