Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Nov 2015 09:11:48 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 204671] clang floating point wrong around Inf (i386)
Message-ID:  <bug-204671-8-k83ncLHcjd@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-204671-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-204671-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 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
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. With the current install base, I'd prefer to see an option in
installer which suggests something like "-march=nocona -mtune=native" for local
builds. (This also hints at the very old topic with having a subtarget for
binary builds for modern processors, since 99% of them are at least P3, and
deliver them for freebsd-update... but this is definitely not the current
ticket issue...) For this particular installation, I had neither strong reason
nor inspiration to convert it to 64-bit one, so still are many users. So,
make.conf will be loaded with weird constructs like

NO_CPU_CFLAGS=true
NO_CPU_COPTFLAGS=true
.if ${.CURDIR:N*/BSD/src/*} == ""
CFLAGS+= -march=nocona -mtune=k8 -mmmx -msse -msse2
COPTFLAGS+= -march=i686 -mtune=k8
.endif

> Clang has a bug about the pragma, https://llvm.org/bugs/show_bug.cgi?id=8100, which has been open for five years with various duplicates but no other significant action.

As soon as they rely on GCC frontend, I doubt this will be fixed until GCC guys
implement its support on their side.

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204671-8-k83ncLHcjd>