Date: Sun, 11 Jun 2017 17:51:36 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-questions@freebsd.org Subject: Re: -O2 flag Message-ID: <cfed0594-b1ff-e198-84ea-bca54eb74496@pinyon.org> In-Reply-To: <1497180132.3245.9.camel@mailman-hosting.com> References: <593C4679.5010104@gmail.com> <20170610223753.4e37600d2c32d0b689144e00@yahoo.es> <593C8DE1.4060803@gmail.com> <1497145677.3245.5.camel@mailman-hosting.com> <74d71bbd-a177-5fbc-8ed2-ca42e3f4915c@pinyon.org> <1497180132.3245.9.camel@mailman-hosting.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/11/17 04:22, Jim Ohlstein wrote: > On Sat, 2017-06-10 at 19:24 -0700, Russell L. Carter wrote: >> On 06/10/17 18:47, Jim Ohlstein wrote: >>> >>> On Sat, 2017-06-10 at 21:25 -0300, Friedrich Locke wrote: >>>> >>>> i switched to clan40, same error, i.e., it still persist. >>>> >>>> The problem is that open OpenBSD/amd64 6.1, "gcc -O2" works 100 >>>> %. >>>> >>>> What could it be the problem ? >>> As a practical suggestion, how about installing one of the versions >>> of >>> gcc in ports and using that to compile your app? >>> >>> >> He's tried both gcc and clang and the result was the same. The >> problem >> is most likely an assumption about the values on the stack, given >> that >> the application "works" on openbsd. > > One of us has misread, but I took his statement to read that it > compiles with gcc -02 on OpenBSD. He's tried two versions of clang on > FreeBSD (38 and 40). Oh I misread, sorry. However, I am trying to emphasize that after multiple compiler (major versions), it is unlikely that it's a compiler bug. I've compiled millions of LOC over hundreds of different compilers in the last 30 years and not once has this sort of error been the compiler's fault. (I am sure somebody else has had the misfortune to have it happen to them, though, law of nature) In addition to the potential stack issue, there's another source of behavior like this. If it's numeric code it can be an unstable algorithm. Back in the early '90s when we were developing the first version of the NAS Parallel Benchmarks we saw this quite frequently. There a variety of ways a numerical algorithm can fail, but for instance sometimes the imputed threshold for "success" is not sufficient for a non-deterministic mapping out to multiple processors. Sometimes algorithms are very sensitive to eg the summation order. So we had to work hard to get algorithms that produced "correct" results over many quite different parallel hardware and programming architectures. As a form of nostalgia for simpler times when details like these mattered, I take probably inordinate interest in Steve Kargl and BDE's algorithm discussions. It takes a lot of work to get the corner cases correct. Best, Russell >> >> These stack details were pointed out previously and all the new >> evidence >> only increases the likelihood that it is a stack problem in the code. >> >> No guarantees, though. >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cfed0594-b1ff-e198-84ea-bca54eb74496>