> On 31 Oct 2019, at 22:07, David Blaikie <dblai...@gmail.com> wrote: > >> On Thu, Oct 31, 2019 at 1:51 PM Hans Åberg <haber...@telia.com> wrote: >> >> > 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. > > Yep, that's certainly their call - there's a cost to maintaining > compatibility with each compiler/toolchain/platform, etc.
Yes, it involves hard study of the various CPUs used. > 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. Both GCC and Clang can be conveniently installed using MacPorts. The Apple inhouse clang is weird. >> > 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. > > Certainly - which is why it's not practical for compiler engineers to be > spending all that time on everyone's bugs, right? It depends, for example, I recently found bug in the GCC C++ regex library, and in the process found an algorithm do compute matches in linear time via some reverse NFA lookups, eliminating the need for backtracking. Regardless how they resolve on GCC, I may have use of it myself. >> > 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. > > 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. I just noticed the issue, and can not give any good advice on how to attack it. _______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
