RFR (S): Failure after windows compiler upgrade
david.holmes at oracle.com
Tue Apr 28 10:50:09 UTC 2015
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.
>> 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
> 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
>> 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.
>> I'd accept the current fix as a temporary workaround to get the tests
>> passing again.
More information about the hotspot-dev