[cfe-users] Clang9 UBSan and GMP

[David Blaikie via cfe-users]

On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg <haberg-1 at telia.com> wrote:

>
> > On 30 Oct 2019, at 23:50, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >> On Wed, Oct 30, 2019 at 2:29 PM Hans Åberg <haberg-1 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20191030/c005621e/attachment.html>