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


Reply via email to