3 ms·

> Regardless of where one wishes to put the blame, this problem will _not_ be fixed. Period. I realise that floating-point numbers are, to use the technical t

by shruubi 10y ago

> Regardless of where one wishes to put the blame, this problem will _not_ be fixed. Period. I realise that floating-point numbers are, to use the technical term, "whack", and I also realise that triaging the issue seems to point to a hardware error, not a software error, but I can't get passed this "yeah, there is a problem, so what?" attitude. Am I missing something critical here that makes this unreasonable to work around or fix?

x0x0 10y ago
It's not a hardware error at all. If you want to use ieee 784 on a processor, you have to learn how it works; there are some subtleties whose root cause is attempting to approximate infinite precision mathematics in a finite precision processor.
pizza234 10y ago
According [indirectly] to one of the comments, the issue is that there is no solution which solves all the problems in the context. Reference: https://gcc.gnu.org/ml/gcc/2003-08/msg01257.html https://gcc.gnu.org/ml/gcc/2003-08/msg01257.html Specifically: There are two things missing. The abililty to turn on the workaround in c (i.e. emit FP rounding instruction after every operation), and a bug fix for the register spills. Even with those things, I think we are still in trouble. In the first case, having explicit rounding instructions eliminates the excess precision problem, but it introduces a double-rounding problem. So we have lost again there. This is probably not fixable without changing the hardware. In the second case, fixing the problem with reload spills eliminates one source of unpredictable rounding, however, we still have the problem that local variables get rounded if they are allocated to the stack and not rounded if they are allocated to an FP reg-stack register. Thus we still have the problem that we get different results at different optimization levels. So we still lose there again also. This might be fixable by promoting all stack locals to long double to avoid unexpected rounding, but that will probably cause other problems in turn. It will break all programs that expect assignments doubles will round to double for instance. If we don't promote stack locals, then we need explicit rounding for them, and then we have double-rounding again. I really see no way to fix this problem other than by fixing the hardware. The hardware has to have explicit float and double operations.

by shruubi 10y ago

x0x0 10y ago

It's not a hardware error at all. If you want to use ieee 784 on a processor, you have to learn how it works; there are some subtleties whose root cause is attempting to approximate infinite precision mathematics in a finite precision processor.

pizza234 10y ago

According [indirectly] to one of the comments, the issue is that there is no solution which solves all the problems in the context. Reference: https://gcc.gnu.org/ml/gcc/2003-08/msg01257.html https://gcc.gnu.org/ml/gcc/2003-08/msg01257.html Specifically: There are two things missing. The abililty to turn on the workaround in c (i.e. emit FP rounding instruction after every operation), and a bug fix for the register spills. Even with those things, I think we are still in trouble. In the first case, having explicit rounding instructions eliminates the excess precision problem, but it introduces a double-rounding problem. So we have lost again there. This is probably not fixable without changing the hardware. In the second case, fixing the problem with reload spills eliminates one source of unpredictable rounding, however, we still have the problem that local variables get rounded if they are allocated to the stack and not rounded if they are allocated to an FP reg-stack register. Thus we still have the problem that we get different results at different optimization levels. So we still lose there again also. This might be fixable by promoting all stack locals to long double to avoid unexpected rounding, but that will probably cause other problems in turn. It will break all programs that expect assignments doubles will round to double for instance. If we don't promote stack locals, then we need explicit rounding for them, and then we have double-rounding again. I really see no way to fix this problem other than by fixing the hardware. The hardware has to have explicit float and double operations.