[Bug 204671] clang floating point wrong around Inf (i386)

[Bruce Evans]

On Sun, 22 Nov 2015 a bug that doesn't want replies wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204671
>
> --- Comment #3 from netch at segfault.kiev.ua ---
> (In reply to Jilles Tjoelker from comment #2)
>
> Jilles, thanks for the excellent explanation. This exposes I have lost some
> important advances in floating point (like FENV_ACCESS role and need). But,
>
>> The conversion for printf happens during the inlined fesetround() call, after setting the x87 rounding mode and before calling a function __test_sse to check whether SSE is available.
>
> Isn't this the issue by itself? If fesetround() makes an action which generally
> shall be atomic, no intervention must be allowed during this setting. If it
> can't be explained in inlined version using C, either "asm volatile" should be
> used, or a fully separate function.

The asm is already volatile.  Even more ordering might (and probably would)
make a difference, but this would from accidentally avoiding the compiler
bugs.  Even an inline function gives a sequence point.  The assignment is
supposed to be complete before this.

>> You will generally have fewer problems with weirdly changing floating point results if you use SSE instead of the x87 FPU, assuming your CPUs are new enough.
>
> Yep, SSE is better in all senses, if supported and exploited. But the latter is

No, SSE isn't better in all senses.  It doesn't even support extra
precision for long doubles.  SSE with 128-bit long doubles in hardware
would be better, but i386 would also need 80-bit long doubles in SSE
for some compatibility.  If fully exploited, 80-bit long doubles are
also better for scalar double precision code (they give more accuracy
using faster, simpler methods).  I intentionally didn't fully exploit
the x87 in libm, since the more complicated methods are still needed
for arches that don't have x87.  The main thing that compiler writers
don't like about the x87 is that its extra precision is (almost) always
present (and not choosable at compile time for every operation).  But
this is a feature.

> a separate issue. Default compiler installation for the i386 target still uses
> the least possible CPU (as far as I see from compilation without any options in
> make.conf). Old style option update (CFLAGS?= in make.conf) doesn't work
> anymore.

CFLAGS?= in make.conf never worked, since sys.mk sets CFLAGS earlier.

I use something like:

.if ${CFLAGS} == "-O -pipe"
CFLAGS+=		-mcpu=athlon-xp
.endif

The ifdef avoids doing anything if CFLAGS is not the default (newer FreeBSD
has the bad default of -O2 instead of -O).  Then it adds to CFLAGS instead
of overriding it.  I set CFLAGS on the command line a lot, and the ifdef
prevents changing this if the command line is not the default.

Bruce