RFR (S): Failure after windows compiler upgrade

[David Holmes]

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.

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