RFR (S): Failure after windows compiler upgrade (original) (raw)

David Holmes david.holmes at oracle.com
Tue Apr 28 05:20:18 UTC 2015

Hi Nils,

On 28/04/2015 7:07 AM, Kim Barrett wrote:

On Apr 27, 2015, at 10:10 AM, Nils Eliasson <nils.eliasson at oracle.com> wrote:

A drawback is that this option also prevents any usage of SSE on the i586 platform. That could be a pretty severe drawback. For example, I’ve been working on some GC performance optimizations that can take advantage of SSE when available. I think this change would mean that the relevant code would require compile-time disable and could not use a runtime configuration test (which would succeed and permit SSE usage on anything other than low end embedded or very ancient hardware).

I agree with Kim, this seems an extreme solution for a very specific problem (seems like the FP equivalent of compiling for i486 rather than i686 :( ).

Where is the code that gets compiled to use the _ltod3 ? The VS docs on this flag allude to problems using SEE instructions due to the mix of precision that can result, and that it can be avoided by intermediate assignments:

https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx

So I'm wondering if: a) we can fix this in the source code?; or b) we can fix this by adding the flag only for specific files?; or c) we can fix this by modifying the FP control word to give SSE and x87 the same settings?

Also we have the problem reported in

https://bugs.openjdk.java.net/browse/JDK-8015396

regarding unexpected NaNs. Is it related to the same underlying problem of using SSE/SSE2 instead of x87, or by mixing them?

I'd accept the current fix as a temporary workaround to get the tests passing again.

Thanks, David

More information about the hotspot-dev mailing list