On Wed, 2018-02-28 at 15:52 +0100, Jose E. Roman wrote: > The attached patch seems to fix the problem on the SLEPc side. Don't > know if it is a general solution or not. > We will add the patch to the future patch release slepc-3.8.3, unless > someone suggests a better workaround. > Thanks. > Jose > > > > El 27 feb 2018, a las 18:18, Drew Parsons <dpars...@debian.org> > > escribió: > > > > Can anyone make sense of the build error for SLEPc 3.8.2 on i386? > > ... > > /<<BUILDDIR>>/slepc-3.8.2+dfsg1/include/slepcmath.h:98:26: note: > > called from here > > _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON); > > ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ > > > > Does it mean i386 doesn't actually support FTZ (or > > _MM_FLUSH_ZERO_ON), > > or does gcc need some C99 flags specified on i386 (or a bug fix)?
That patch looks great, thanks Jose. I had a feeling it will be something about the supported machine code like that. I had tried a patch which tests for __i386__, which of course enables the i386 build to proceed. But your test for __SSE__ is much better, it properly captures the specific support in the chipsets. I've found more discussion at https://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz which confirms __SSE__ is the right test for FTZ. You'll want __SSE2__ if you start manipulating DAZ instead. Should probably check to make certain, are there any architectures (non-intel) which support FTZ (and MM_FLUSH_ZERO) but not through SSE? A quick survey of Debian non-intel machines (arm64, mipsel, powerpc, s390x) says they won't have SSE, but they don't have xmmintrin.h either. So your patch should be safe, since the test for PETSC_HAVE_XMMINTRIN_H will catch these cases. Thanks again, Drew
