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

David Holmes david.holmes at oracle.com
Tue Apr 28 10:50:09 UTC 2015

Hi Nils,

On 28/04/2015 5:15 PM, Nils Eliasson wrote:

Hi David,

On 2015-04-28 07:20, David Holmes wrote: 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: A cast of a long to a float. In any place calling l2f() for example. In happens regardless of optimization level.

Do we do that a lot? If we can change l2f() wouldn't that suffice?

The problem with vs2013 is that it emits an intermediate assignment we shouldn't have.

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

So I'm wondering if: a) we can fix this in the source code?; or No. b) we can fix this by adding the flag only for specific files?; or Yes but I haven't seen any preparations for that in our makefiles. It would be a bit fragile solution.

Windows build doesn't support the CFLAGS/BYFILE construct.

c) we can fix this by modifying the FP control word to give SSE and x87 the same settings? No, it is the choice of instructions that is wrong. They explicitly cast the long to a double first and then to the float.

So really this is a VS compiler bug? (not that that helps us in any way).

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? That is a separate problem.

But presumably related.

Thanks, David

I'd accept the current fix as a temporary workaround to get the tests passing again. Thanks, David ok, Thanks, Nils

More information about the hotspot-dev mailing list