RFR (S): Failure after windows compiler upgrade
david.holmes at oracle.com
Tue Apr 28 05:20:18 UTC 2015
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
More information about the hotspot-dev