> On 31 Oct 2019, at 21:40, David Blaikie <dblai...@gmail.com> wrote: > >> On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg <haber...@telia.com> wrote: >> >> > On 31 Oct 2019, at 18:40, David Blaikie <dblai...@gmail.com> wrote: >> > >> >> Right, but that is something one would avoid when computing arithmetical >> >> results. >> > >> > 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. >> >> Nor whether it is a compiler bug. > > 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.
GMP is not the average program, though. > 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. 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. > Apologies for the snark in the title of this article, but it covers some of > the ideas: > https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/ > & other articles around discuss similar ideas. 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. > 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). GMP is indeed very complex, not only from a programming point of view, but also the underlying algorithms. _______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
