On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg <haber...@telia.com> wrote:
> > > On 30 Oct 2019, at 23:50, David Blaikie <dblai...@gmail.com> wrote: > > > >> On Wed, Oct 30, 2019 at 2:29 PM Hans Åberg <haber...@telia.com> wrote: > >> 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. > >> > > 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. > > 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. > Ah, fair enough - that narrows down the points of failure a little. >> 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. > > > > 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). > > > > 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. > > 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. :-) > 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. - Dave > > 1. https://gmplib.org/list-archives/gmp-discuss/2019-April/006319.html > > >
_______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
