#1013 mvnksearch.c:440: SortRestricted: Assertion `r1B' failed.

[Jeroen Demeyer]

When building ATLAS on a POWER8 ppc64le system, I got this error:

xmvnksearch: /home/jdemeyer/sage/local/var/tmp/sage/build/atlas-3.11.38/src/ATLAS-build/../ATLAS//tune/blas/gemv/mvnksearch.c:440: SortRestricted: Assertion `r1B' failed.

I also saw this error, I am not sure if they are related:

/home/jdemeyer/sage/local/var/tmp/sage/build/atlas-3.11.38/src/ATLAS-build/../ATLAS//tune/blas/level3/tsmfc.c: In function 'GetFlags':
/home/jdemeyer/sage/local/var/tmp/sage/build/atlas-3.11.38/src/ATLAS-build/../ATLAS//tune/blas/level3/tsmfc.c:62:9: error: 'NB' undeclared (first use in this function)
    *M = NB;
         ^
/home/jdemeyer/sage/local/var/tmp/sage/build/atlas-3.11.38/src/ATLAS-build/../ATLAS//tune/blas/level3/tsmfc.c:62:9: note: each undeclared identifier is reported only once for each function it appears in
/home/jdemeyer/sage/local/var/tmp/sage/build/atlas-3.11.38/src/ATLAS-build/../ATLAS//tune/blas/level3/tsmfc.c: In function 'main':
/home/jdemeyer/sage/local/var/tmp/sage/build/atlas-3.11.38/src/ATLAS-build/../ATLAS//tune/blas/level3/tsmfc.c:104:14: error: 'NB' undeclared (first use in this function)
       nn = 3*NB;
              ^
Makefile:174: recipe for target 'stsmfc.o' failed
make[9]: *** [stsmfc.o] Error 1

[Jeroen Demeyer]

This happened just once, I have built ATLAS successfully on this machine.

[R. Clint Whaley]

One big problem is that you have not turned off all those virtual processors, which means that if this install had completed, your parallel BLAS would run slower than your serial BLAS, and the serial BLAS would probably be bad as well due to timing error.

On my 4-core POWER8, I add the flag
--force-tids="4 0 8 16 24"

See some old info at:
http://math-atlas.sourceforge.net/atlas_install/node21.html

Have you been adding this flag normally, and only forgot it for this bad install?

[Jeroen Demeyer]

I was not aware of the fact that those virtual processors should be disabled.

But still: is this related to the build failure? I mean, can building a non-efficient ATLAS cause build failures?

[R. Clint Whaley]

Yes it can, but you are right to be skeptical that this is necessarily the case here.

The most straightforward way to see how this could happen is that bad timings make it so cases using huge numbers of assumed registers win. Then, later on in the install, this results in such huge kernels that gcc dies in the optimization phase, which means an install doesn't finish even with completely correct ATLAS, due only to bad timings. It can result in compilable kernels being produced, which of course kills the install.

There are several other scenarios where this kind of thing happens, but find bugs in weird corner cases of the generator that are simply never explored on any sane machine (i.e., then the bug is in a generator corner case, rather than the system compiler).

The problem is that most of these intermittent install cases are not very rewarding to track down: huge amounts of work, that often end in "I cannot get the case to repeat", or "I got it to repeat once, but was unable to learn why, and I can't figure anything out by inspection". So, I tend to simply find the first problem, and look deeper only if the problem occurs with a good install.

About the only time I try to track down these intermittent problems that don't occur when installed correctly is for stabilization, and even then I often fail after a huge amount of work. 3.11.38 is, unfortunately, not close to stable (3.11.39 will be an almost complete rewrite of most of it).