From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6318 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: =?utf-8?B?UkXvvJpbQlVHXVttYXRo?= =?utf-8?Q?=5Dbuil?= =?utf-8?Q?d?= musl with optimizing flags, some math functions are broken. Date: Tue, 14 Oct 2014 11:12:12 -0400 Message-ID: <20141014151212.GO32028@brightrain.aerifal.cx> References: <20141014024238.GL32028@brightrain.aerifal.cx> <20141014030325.GM32028@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413299558 4557 80.91.229.3 (14 Oct 2014 15:12:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Oct 2014 15:12:38 +0000 (UTC) Cc: musl To: bobodog <8192542@qq.com> Original-X-From: musl-return-6331-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 14 17:12:33 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xe3m3-0000vi-6V for gllmg-musl@plane.gmane.org; Tue, 14 Oct 2014 17:12:31 +0200 Original-Received: (qmail 24254 invoked by uid 550); 14 Oct 2014 15:13:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24243 invoked from network); 14 Oct 2014 15:13:27 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6318 Archived-At: On Tue, Oct 14, 2014 at 03:09:45PM +0800, bobodog wrote: > Further confirmation, the problem is -ffast-math flag, just remove > this flag, all tests passed, please fix this bug, the openbsd's msun > math library, have not any problem with this flags. This is not a bug. The documented purpose of the -ffast-math flag is to unconstrain the compiler from having to provide correct results for floating point math operation, in hopes of producing faster code. It is documented as: Sets -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range. This option causes the preprocessor macro __FAST_MATH__ to be defined. This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. (Source: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) The patches you provided are not valid; they simply cause perturbations in the compiler's output that makes the functions happen to work for your particular version of GCC and CFLAGS. But there is no reason they should make it work. The problem is -ffast-math. The only way to implement the math part of the standard library that's compatible with -ffast-math would be to write the whole thing using explicit soft-float, which would be very slow. Just remove -ffast-math and the problem should go away. Note that -mfpu=neon may also break some things in the standard library, and it will not help. There are no functions in the standard library which benefit from vectorization of floating point math. The breakage from using neon should be much smaller (probably limited to cases of denormal arguments) but you're not gaining anything by using it, so it would make sense to remove that too. There is nothing wrong with using -ffast-math or -mfpu=neon to compile your _applications_ as long as those applications don't need rigorously correct math results. But these options should not be used for compiling the standard library. Rich