<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 2:29 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">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.</blockquote><div><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> </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></blockquote><div><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>- 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>
<br>
> On 30 Oct 2019, at 22:17, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
> I ran the test & understand it a bit better now - so the abort is part of the code, when the test fails, the test harness uses abort to fail.<br>
> <br>
> So this isn't "clang causes abort" (it didn't select a bad instruction, etc) this is "clang causes test failure" - this could be any number of things in terms of compiler optimizations due to overly dependent code (or due to miscompiles, to be sure). It's possible the test relies on specific numeric results that the C++ programming language doesn't guarantee (either overly high precision, or overly low precision - C++ allows extra precision in computations which can break numerical code that's relying on certain precision, for instance).<br>
> <br>
> So, yeah, really hard to say where the fault lies without further investigation.<br>
> <br>
> On Fri, Oct 25, 2019 at 4:13 PM Hans Åberg <<a href="mailto:haberg-1@telia.com" target="_blank">haberg-1@telia.com</a>> wrote:<br>
> The GMP developers felt it was a compiler bug, so I think I will leave it at that. But thanks for the tips.<br>
> <br>
> <br>
> > On 26 Oct 2019, at 00:32, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> > <br>
> > UBSan doesn't catch everything - you could also try ASan and/or valgrind, etc. (MSan if you want, but that's a bit fussier/more work to use)<br>
> <br>
<br>
</blockquote></div></div>