RFR (S): Failure after windows compiler upgrade

[Nils Eliasson]

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.

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.

> 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.

>
> 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.

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

ok,

Thanks,
Nils