On Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor <i...@google.com> wrote: > Richard Guenther <richard.guent...@gmail.com> writes: > >> On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor <i...@google.com> wrote: >>> The master Go math library uses assembler code on 386 processors to take >>> advantage of 387 instructions. This patch lets gccgo do the same thing, >>> by compiling the math library with -funsafe-math-optimizations. I also >>> pass -mfancy-math-387, although that is the default. It would not be >>> appropriate to compile all Go code with -funsafe-math-optimizations, of >>> course, but the math library is designed to handle it. >> >> Huh ... I'd rather not do that if I were you. Instead I'd say we lack a >> machine specific flag to enable the fancy-x87-math patterns which >> then -funsafe-math-optimizations should enable. The x87 math >> routines are the only thing you are after, right? No math-library >> can be _safe_ against -funsafe-math-optimizations I believe. > > Yes, that approach would make sense, but this doesn't seem like the > right time to do it. > > The -funsafe-math-optimizations option does not permit arbitrary > behaviour. It merely permits a set of optimizations which violate > strict IEEE conformance. I believe the Go math library can be safe in > the presence of those optimizations, because the library does explicit > checks for NaN and infinity, where necessary, before it does the actual > operation. The math library has a fairly extensive set of tests, > including tests of exceptional conditions, and it passes the tests when > using -funsafe-math-optimizations. Note that I'm only using > -funsafe-math-optimizations on x86.
I see. -funsafe-math-optimizations affects precision though (it doesn't assume NaNs or Infinities do not happen), see the docs - it enables -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math. Richard. > Ian
