<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 5:36 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>
<br>
> On 31 Oct 2019, at 00:28, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg <<a href="mailto:haberg-1@telia.com" target="_blank">haberg-1@telia.com</a>> wrote:<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>
> <br>
> Ah, fair enough - that narrows down the points of failure a little.<br>
<br>
In addition, they use assembly code, but that can be turned off with configure --disable-assembly, though I did not 'make check' with that.<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>
> <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>
Yes, but assuming that the GMP adheres to the C standard, there should be no difference in the arithmetical values produced.<br></blockquote><div><br></div><div>Not necessarily - C (well, I don't know the C standard as well as I know the C++ standard, admittedly) does allow various variations (implementation and unspecified behavior, for instance). eg: order of evaluation of function arguments (not that this is likely to vary due to optimizations - and doesn't with clang to the best of my knowledge, but as an example of the /sort/ of thing):<br><br>  int f() {<br>    static int i = 0;<br>    return i++;<br>  }<br>  int f2(int i, int j) {<br>    return i;</div><div>  }<br>  int main() {<br>    return f2(f(), f());<br>  }<br><br>This program could exit with 0 or 1 - both results are valid interpretations of the program per the standard. (again, I don't know the C spec quite as well, so I'm not sure exactly what it says about this code)<br><br>And the assumption that GMP adheres to the C standard isn't one, as a compiler developer, I'd be willing to make without more data - (heck, even the compiler itself has some "intentional" undefined behavior in it... )<br><br>- Dave</div></div></div>