<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg <<a href="mailto:haberg-1@telia.com">haberg-1@telia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On 30 Oct 2019, at 23:50, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
>> On Wed, Oct 30, 2019 at 2:29 PM Hans Åberg <<a href="mailto:haberg-1@telia.com" target="_blank">haberg-1@telia.com</a>> wrote:<br>
>> Indeed, very hard to figure out. If it is some hidden undefined behavior causing it, the UBSan should have caught it, but it does not.<br>
>> <br>
> Right - but especially with numerics (especially floating point) there's loads of room for valid but different behavior between different compilers - behavior that isn't UB. How much precision a certain mathematical equation maintains is really at the whim of the optimizers in a lot of ways.<br>
<br>
I believe that GMP is just using integer types, and then uses that to make multiprecision integers, rational numbers, and floating point numbers. At least MPFR uses only the integer and rational number part of GMP, and builds multiprecision floating point numbers on top of that, which is necessary because of special requirements of the standards they adhere to.<br></blockquote><div><br>Ah, fair enough - that narrows down the points of failure a little.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> The link that Matthew gave says that the GMP developers experienced a number of such issues with Clang. One can though turn off the optimizer, and the tests pass.<br>
> <br>
> Sure - most of the numeric effects would only appear with optimizations. Without them every numeric operation's just done in registers, then written right back to memory (so no chance of excess precision leaking in by storing the value in an 80bit floating point register between multiple operations, or any risk of fused operations that produces extra precision, etc). <br>
> <br>
> The only way to know is to trace down/reduce the point where the values diverge & stare at the code to see who's right.<br>
<br>
GMP has been used in three years in a sequenced operation that must be exact and without errors to solve the problem [1], and I would think it used GCC with optimizations. So that puts Clang in a tough spot. :-)<br></blockquote><div><br>Not as much as it would seem - again, the spec allows for a fair bit of flexibility in a bunch of ways. (admittedly, within integer arithmetic without invoking UB (but, again, that's not proven - UBSan isn't guaranteed to catch everything)) Different compilers optimize code in different ways - that the code "works"/produces the desired behavior on one compiler/under some optimizations and not others doesn't give us much idea about whether the code or the compiler is correct. Different behavior is acceptable in C++ in a bunch of ways & compilers rely on that flexibility.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
1. <a href="https://gmplib.org/list-archives/gmp-discuss/2019-April/006319.html" rel="noreferrer" target="_blank">https://gmplib.org/list-archives/gmp-discuss/2019-April/006319.html</a><br>
<br>
<br>
</blockquote></div></div>