<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2019 at 1:51 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 31 Oct 2019, at 21:40, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
>> On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg <<a href="mailto:haberg-1@telia.com" target="_blank">haberg-1@telia.com</a>> wrote:<br>
>> <br>
>> > On 31 Oct 2019, at 18:40, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>> > <br>
>> >> Right, but that is something one would avoid when computing arithmetical results.<br>
>> > <br>
>> > One would try to, yes - but that's sort of what the whole discussion is resolving around: Is the code correct? I don't know. I wouldn't assume it is (I'm not assuming it isn't either) - but without a reduced test case that gets to the root of the difference in behavior, we don't know if the code is correct.<br>
>> <br>
>> Nor whether it is a compiler bug.<br>
> <br>
> Indeed - but you can imagine that, on average (just due to there being way more code compiled by the compiler, than the code of the compiler itself) the bug is in external code, not the compiler.<br>
<br>
GMP is not the average program, though.<br>
<br>
> Such that it's not practical for the compiler developers to do all the leg work of investigating 3rd party code bugs to determine if it's a bug in the compiler. It doesn't scale/we wouldn't have any time to work on the compiler & most of the time we'd be finding user bugs, not compiler bugs.<br>
<br>
The GMP developers feel exactly the same, dropping Clang support. It is mostly a problem for MacOS users that do not have access to GCC.<br></blockquote><div><br>Yep, that's certainly their call - there's a cost to maintaining compatibility with each compiler/toolchain/platform, etc. If you have a personal interest in GMP on MacOS, then perhaps the cost falls to you, if you're willing to pay it, to investigate this sort of thing & help support this particular library+compiler combination, if it's worth your time to do so.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Apologies for the snark in the title of this article, but it covers some of the ideas: <a href="https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/" rel="noreferrer" target="_blank">https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/</a> & other articles around discuss similar ideas.<br>
<br>
This article is pretty naive: Yes, it is a good starting point to check ones own code first, but eventually one learns to identify compiler bugs as well. It is very time consuming, though.<br></blockquote><div><br>Certainly - which is why it's not practical for compiler engineers to be spending all that time on everyone's bugs, right?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Yes, there are compiler bugs - but you've sort of got to continue under the assumption that that's not the issue until you've got some fairly compelling evidence of one (very narrow test case where you can look at all the code & visually inspect/discuss/reason about its standards conformance - currently "all of GMP" is too big to apply that level of scrutiny).<br>
<br>
GMP is indeed very complex, not only from a programming point of view, but also the underlying algorithms.<br></blockquote><div><br>Yep - which makes it all the harder for me or someone else on the LLVM project to likely be able to find any potential compiler bugs in it.<br><br>- Dave</div></div></div>