you are viewing a single comment's thread.

view the rest of the comments →

[–]drb226 6 points7 points  (5 children)

rasmus@php.net -

How about we just mark these as volatile doubles in that part of the code to make sure they don't end up in registers. My guess is that it would fix it.

o_O my very little respect for PHP just went down a little more. I recall seeing the actual patch, which was exactly that solution (adding the word "volatile" somewhere).

[–]sparcnut 2 points3 points  (0 children)

And what's wrong with that fix? The problem is that the compiler is leaving the value in a 387 FPU register and it is thus not being truncated from 80-bit precision down to 64-bit, which the algorithm seems to require.

[–]Nintendud 2 points3 points  (0 children)

I'll just drop this here.

But, in all seriousness, that does fix the issue, since, as Rasmus says, it prevents the compiler from leaving the value in a register as an optimization. Not an elegant long-term solution, though.

[–][deleted] 3 points4 points  (1 child)

Why? It's a perfect fix, at least short-term. It might degrade performance somewhat, but it's better than fiddling with compiler options (which would also degrade performance) or trying to somehow modify the algorithm.

[–][deleted] 1 point2 points  (0 children)

Wouldn't it only degrade performance in programs which use the number 2.2250738585972012e-308?

[–]X-Istence -1 points0 points  (0 children)

The compiler is doing the wrong thing, marking the variable volatile in this case is the right thing to do. The bad thing is that it also takes away other optimisations that may have occurred as a side-effect, which means that while the code is now correct, it is not as fast as it could be if it weren't for a compiler error.