[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Oct 2014 11:12:12 -0400
From: Rich Felker <dalias@...c.org>
To: bobodog <8192542@...com>
Cc: musl <musl@...ts.openwall.com>
Subject: Re: RE：[BUG][math]build musl with optimizing flags, some math functions are broken.
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
