Closed mrader1248 closed 6 years ago
As gcc 7.3 is rather new, I also tested gcc 7.2 -- same problem.
Could you please tell us:
1) What OS version you are using, 2) What processor you are using, 3) Your complete configure line and output? 4) What version/git commit of BLIS you are using?
./configure --prefix=${INSTALL_DIR} --enable-shared --enable-static --enable-blas --enable-cblas CC=gcc-7.3 haswell
, output belowconfigure: reading configuration registry...done.
configure: checking whether we need to update the version file.
configure: checking version file './version'.
configure: found '.git' directory; assuming git clone.
configure: executing: git describe --tags.
configure: got back 0.3.0-29-g97e1eea.
configure: truncating to 0.3.0-29.
configure: updating version file './version'.
configure: starting configuration of BLIS 0.3.0-29.
configure: configuring with official version string.
configure: manual configuration requested; configuring with 'haswell'.
configure: checking configuration against contents of 'config_registry'.
configure: configuration 'haswell' is registered.
configure: 'haswell' is defined as having the following sub-configurations:
configure: haswell
configure: which collectively require the following kernels:
configure: haswell zen
configure: checking sub-configurations:
configure: 'haswell' is registered...and exists.
configure: checking sub-configurations' requisite kernels:
configure: 'haswell' kernels...exist.
configure: 'zen' kernels...exist.
configure: using install prefix '/scratch/csaq9425/sw/libs/blis_gcc73_single'.
configure: debug symbols disabled.
configure: disabling verbose make output. (enable with 'make V=1'.)
configure: building BLIS as a static library.
configure: building BLIS as a shared library.
configure: threading is disabled.
configure: internal memory pools for packing buffers are enabled.
configure: the BLAS compatibility layer is enabled.
configure: the CBLAS compatibility layer is enabled.
configure: the internal integer size is automatically determined.
configure: the BLAS/CBLAS interface integer size is 32-bit.
configure: creating ./config.mk from ./build/config.mk.in
configure: creating ./bli_config.h from ./build/bli_config.h.in
configure: creating ./obj/haswell
configure: creating ./obj/haswell/config
configure: creating ./obj/haswell/config/haswell
configure: creating ./obj/haswell/kernels
configure: creating ./obj/haswell/kernels/haswell
configure: creating ./obj/haswell/kernels/zen
configure: creating ./obj/haswell/ref_kernels
configure: creating ./obj/haswell/ref_kernels/haswell
configure: creating ./obj/haswell/frame
configure: creating ./obj/haswell/blastest
configure: creating ./obj/haswell/testsuite
configure: creating ./lib/haswell
configure: creating ./include/haswell
configure: mirroring ./config/haswell to ./obj/haswell/config/haswell
configure: mirroring ./kernels/haswell to ./obj/haswell/kernels/haswell
configure: mirroring ./kernels/zen to ./obj/haswell/kernels/zen
configure: mirroring ./ref_kernels to ./obj/haswell/ref_kernels/haswell
configure: mirroring ./frame to ./obj/haswell/frame
configure: creating makefile fragment in ./config/haswell
configure: creating makefile fragment in ./kernels/haswell
configure: creating makefile fragment in ./kernels/haswell/3
configure: creating makefile fragment in ./kernels/zen
configure: creating makefile fragment in ./kernels/zen/1
configure: creating makefile fragment in ./kernels/zen/1f
configure: creating makefile fragment in ./kernels/zen/3
configure: creating makefile fragment in ./ref_kernels
configure: creating makefile fragment in ./ref_kernels/1
configure: creating makefile fragment in ./ref_kernels/1f
configure: creating makefile fragment in ./ref_kernels/1m
configure: creating makefile fragment in ./ref_kernels/3
configure: creating makefile fragment in ./ref_kernels/ind
configure: creating makefile fragment in ./frame
configure: creating makefile fragment in ./frame/0
configure: creating makefile fragment in ./frame/0/copysc
configure: creating makefile fragment in ./frame/1
configure: creating makefile fragment in ./frame/1d
configure: creating makefile fragment in ./frame/1f
configure: creating makefile fragment in ./frame/1m
configure: creating makefile fragment in ./frame/1m/packm
configure: creating makefile fragment in ./frame/1m/scalm
configure: creating makefile fragment in ./frame/1m/unpackm
configure: creating makefile fragment in ./frame/2
configure: creating makefile fragment in ./frame/2/gemv
configure: creating makefile fragment in ./frame/2/ger
configure: creating makefile fragment in ./frame/2/hemv
configure: creating makefile fragment in ./frame/2/her
configure: creating makefile fragment in ./frame/2/her2
configure: creating makefile fragment in ./frame/2/symv
configure: creating makefile fragment in ./frame/2/syr
configure: creating makefile fragment in ./frame/2/syr2
configure: creating makefile fragment in ./frame/2/trmv
configure: creating makefile fragment in ./frame/2/trsv
configure: creating makefile fragment in ./frame/3
configure: creating makefile fragment in ./frame/3/gemm
configure: creating makefile fragment in ./frame/3/gemm/ind
configure: creating makefile fragment in ./frame/3/hemm
configure: creating makefile fragment in ./frame/3/her2k
configure: creating makefile fragment in ./frame/3/herk
configure: creating makefile fragment in ./frame/3/symm
configure: creating makefile fragment in ./frame/3/syr2k
configure: creating makefile fragment in ./frame/3/syrk
configure: creating makefile fragment in ./frame/3/trmm
configure: creating makefile fragment in ./frame/3/trmm3
configure: creating makefile fragment in ./frame/3/trsm
configure: creating makefile fragment in ./frame/base
configure: creating makefile fragment in ./frame/base/check
configure: creating makefile fragment in ./frame/base/noopt
configure: creating makefile fragment in ./frame/compat
configure: creating makefile fragment in ./frame/compat/cblas
configure: creating makefile fragment in ./frame/compat/cblas/f77_sub
configure: creating makefile fragment in ./frame/compat/cblas/src
configure: creating makefile fragment in ./frame/compat/check
configure: creating makefile fragment in ./frame/compat/f2c
configure: creating makefile fragment in ./frame/compat/f2c/util
configure: creating makefile fragment in ./frame/include
configure: creating makefile fragment in ./frame/include/level0
configure: creating makefile fragment in ./frame/include/level0/1e
configure: creating makefile fragment in ./frame/include/level0/1m
configure: creating makefile fragment in ./frame/include/level0/1r
configure: creating makefile fragment in ./frame/include/level0/io
configure: creating makefile fragment in ./frame/include/level0/ri
configure: creating makefile fragment in ./frame/include/level0/ri3
configure: creating makefile fragment in ./frame/include/level0/rih
configure: creating makefile fragment in ./frame/include/level0/ro
configure: creating makefile fragment in ./frame/include/level0/rpi
configure: creating makefile fragment in ./frame/ind
configure: creating makefile fragment in ./frame/ind/cntx
configure: creating makefile fragment in ./frame/ind/misc
configure: creating makefile fragment in ./frame/ind/oapi
configure: creating makefile fragment in ./frame/ind/tapi
configure: creating makefile fragment in ./frame/ind/ukernels
configure: creating makefile fragment in ./frame/thread
configure: creating makefile fragment in ./frame/util
configure: configured to build within top-level directory of source distribution.
OK, I can replicate this and will look into it.
Thank you very much for your quick response!
No problem, thanks for the bug report. Look like a doozy!
My default assumption is that this is a compiler bug, given that so many compilers before/other than gcc 7.2/7.3 do not show any problems. (Granted, it's always possible we're using some sloppy syntax that is no longer forgiven in those versions.)
@devinamatthews Thanks for looking into this.
@mrader1248 we've found the problem and I believe @fgvanzee is working on a fix (unless you want me to do it).
@devinamatthews I'll commit a fix to the issue @mrader1248 pointed out. Thanks for your help identifying the root cause.
@mrader1248 Please try e2192a8f and let us know if the test failures persist or go away. Thanks for your feedback.
Thank you very much for your great help! Now everything works as expected. Looking forward to benchmarking. Just for curiosity's sake: Why is the zen code needed for the haswell config? Will this commit be included into the latest version?
@mrader1248 Glad we were able to fix your problem. (Devin tracked down the issue quickly.)
Just for curiosity's sake: Why is the zen code needed for the haswell config?
While the Haswell, Broadwell, Skylake, Kabylake, Coffeelake, and Zen microarchitectures are all distinct, they actually share roughly the same instruction set (at least for our purposes) and number of vector registers. The net effect of this is that we can recycle kernel code across those microarchitectures, even if each of those systems would ideally use different cache blocksizes (which can be encoded in the individual sub-configurations, e.g. haswell
vs. zen
) .
So, we could have labeled the kernels as haswell
and imported them into the zen
configuration, and the result would have been the same.
Will this commit be included into the latest version?
I'm not sure if I understand the question. If you are asking if this commit will be merged into master
, the answer is absolutely. (In fact, I just did.)
If you are asking if this commit will make it into the next version number, the answer is the same (yes). Please note that when we bump the version number is somewhat arbitrary. But rest assured that there is nothing special about using a commit that has a fresh version number; it's just an arbitrary milestone. We are constantly making improvements, in part thanks to great feedback from contributors such as yourself, and so we strongly encourage our users, especially those engaged with developers, to use the head commit of the master
(or dev
) branch, rather than the latest tagged version.
Thank you for the clarification.
Yes, to be 'git-precise': I wanted to know whether this commit will be merged into master
, such that I have to work with a specific commit no longer.
Thank you all again for your help!
@mrader1248 Would you care to reveal your real name so I can acknowledge your contribution in our upcoming 0.3.1 announcement? No worries if you'd rather stay anonymous.
It's Michael Rader, but in the end you did the job, I just found a bug.
@mrader1248 Thanks Michael. Nevertheless, we like to acknowledge such contributions. (The ability to fix a bug does us no good if we don't know the bug exists.)
I have successfully built and tested BLIS with icc (2015) using
make check
. However, when I use gcc 7.3 together with the binutils 2.30 (on the same machine), some tests fail. As far as I can tell, only real test cases are affected. I ranconfigure
with the options--enable-shared --enable-static --enable-blas --enable-cblas
. Attached to this message you can find the blocks ofoutput.testsuite
where test cases fail.