Re: [lmi] [PATCH] Better support for non-x87 platforms

[Vadim Zeitlin]

On Thu, 5 Jan 2017 15:17:37 +0000 Greg Chicares <address@hidden> wrote:

GC> (BTW, is there any way to detect x87 with clang? Apparently we'd need
GC>   http://stackoverflow.com/questions/22581350/clang-5-1-fpmath
GC> | for Clang to accept -mfpmath=387, I had to also pass -mno-sse
GC> to select it, but does that define a feature macro? and, even if
GC> there's supposed to be a macro, is it correct in light of this:
GC>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632472
GC> ?)

 This corresponds to clang bug https://llvm.org/bugs/show_bug.cgi?id=20602
and it seems that __SSE__ macros are defined in this case because clang
consciously defaults to a CPU (Pentium 4) which is sufficiently modern to
allow using SSE instructions. However after struggling with it for some
time, I failed to find a way to actually disable the use of SSE with clang.
Using -mno-sse does work for getting rid of __SSE__ macros and even emits
x87 instructions in the assembly, but using it to compile any realistic
code involving functions from <cmath> results in

fatal error: error in backend: SSE register return with SSE disabled
clang: error: clang frontend command failed with exit code 70 (use -v to see 
invocation)

I found several bug reports about this error message, but they also seem to
be already fixed in the (very recent) version I'm using or not relevant, so
I'm not sure what's going on here. I'm even less sure whether it makes
sense to spend any more time on this though, I don't see any good reason to
use x87 instructions with clang, do you?

GC> (2) I too didn't like moving LMI_X87 away from LMI_X86. I did that
GC> only to make it follow LMI_MSC, on which it depends, and for which
GC> the inline documentation references this:
GC> 
GC> http://boost.cvs.sf.net/boost/boost/boost/config.hpp?annotate=1.1
GC> //   Many other "compilers define _MSC_VER. Thus BOOST_MSVC."

 FWIW this doesn't seem to be the case any more, as there are just very few
compilers left: all the Metrowerks, Watcom, Symantec and other dmars
compilers of yore are extinct by now and the only remaining compiler still
(possibly?) predefining _MSC_VER I know of is the Intel one, but it's
simple enough to just check for __INTEL_COMPILER first, before checking for
_MSC_VER, if necessary.

GC> I'm not necessarily adamant about (1), but it doesn't seem ideal
GC> to let clang (e.g.) default silently to SSE.

 There are two objections to this: first, clang definitely does default to
SSE (and my experience seems to indicate that it's not that simple to avoid
using SSE with it) and, second, clang predefines __GNUC__ anyhow, so it's
already covered by gcc checks.

GC> I just pushed a change that looks very much like your rewrite
GC> above, and moves the LMI_X86 and LMI_X87 tests into propinquity.

 Thanks! This does (mostly) compiles now but still stops further on with

fenv_lmi.cpp:94:41: error: unused parameter 'precision_mode' 
[-Werror=unused-parameter]

The following trivial patch allows the compilation to succeed (well,
almost: I still have some (compilation) problems in "make check" with
value_cast_test.cpp but they seem to be unrelated, so I'll write about them
separately later):

---------------------------------- >8 --------------------------------------
diff --git a/fenv_lmi.cpp b/fenv_lmi.cpp
index 889f88c..b2472b9 100644
--- a/fenv_lmi.cpp
+++ b/fenv_lmi.cpp
@@ -104,6 +104,7 @@ void fenv_precision(e_ieee754_precision precision_mode)
     control_word.pc(pc);
     x87_control_word(control_word.cw());
 #else  // !defined LMI_X87
+    stifle_warning_for_unused_variable(precision_mode);
     throw std::logic_error("Unable to set hardware precision.");
 #endif // !defined LMI_X87
 }
---------------------------------- >8 --------------------------------------

 Thanks in advance for applying it,
VZ