This issue supersedes 1611882: Original comment: We currently don't support strictfp which means classes that rely on it for their implementation (such as java.lang.StrictMath) have large errors. For example, performing a StrictMath.asin(0.7) leads to the result 0.775397496610753 on cacao, jamvm, kaffe and gij. On the Jikes RVM it returns the result 0.77563157266727708 - we're only accurate for the first 3 decimal places! Because of this bug we can't switch from using the native code in Math to Java code in StrictMath because we fail numerous regression tests. Comment from Dave: If you are actually going to work on this, then it should be done in the context of switching to using SSE2 instead of 387 floating point. There's a ton of code in the opt compiler related to codegen of 387 fp ops that won't work in strict math mode. The overall plan should probably be: (1) implement SSE2 (2) eliminate all "fancy" 387 code (3) support trivial 387 operations on old machines where SSE2 isn't available. SSE2 is a pre-req because you'll take a big performance hit on some benchmarks if you eliminate all the fancy 387 support from the opt compiler without providing something better. Recent status update: So StrictMath.asin(0.7) now looks healthy: baseline 0.775397496610753 opt 0.775397496610753. We're currently not supporting strict math anywhere in the compilers. For baseline this may not be an issue, as the chances of precision gains, etc. are rare (probably just about impossible). For the opt compiler there's a good chance we could gain precision with certain optimizations. Probably the easiest way to find problems is to dig out my StrictMath VMMath patch and run some benchmarks. The fact we completely ignore the fpstrict flag in the entire code base is bound to be an issue somewhere. Alternatively we could do with some decent fpstrict regression tests.