RFR (S): Failure after windows compiler upgrade

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 


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


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.


More information about the hotspot-dev mailing list