Date: Sun, 22 Nov 2015 22:25:18 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-bugs@freebsd.org Subject: Re: [Bug 204671] clang floating point wrong around Inf (i386) Message-ID: <20151122215251.H2638@besplex.bde.org> In-Reply-To: <bug-204671-8-k83ncLHcjd@https.bugs.freebsd.org/bugzilla/> References: <bug-204671-8@https.bugs.freebsd.org/bugzilla/> <bug-204671-8-k83ncLHcjd@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151122215251.H2638>