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 [email protected] ---
(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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
