From owner-freebsd-questions@freebsd.org Mon Jun 12 00:51:39 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6FF7BF07CD for ; Mon, 12 Jun 2017 00:51:39 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from h2.pinyon.org (h2.pinyon.org [65.101.20.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98AA07C324 for ; Mon, 12 Jun 2017 00:51:38 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by h2.pinyon.org (Postfix, from userid 58) id 60380FF1E; Sun, 11 Jun 2017 17:51:37 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1497228697; bh=cku2BkVasK5CyiBUCrgeq0UUYY2W2ynNh02kOVyuxpQ=; h=Subject:To:References:From:Date:In-Reply-To; b=Lc+5VGR30B3CC252zJFEB9Np5nFS2jb++uE/qAi9JwDHCMuuSQCt6qC67tD7lJZLj 703lLkZGN4sc4jPipp5cW/BNsW+wblv1O0Ap/YHjPeaOrid2DyMvWC7fX9lA8WT/SB PjRfgkiCMkb63tqTEjPu+hTpToFEedz/yAv58Fk0= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on h2.n1.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from [10.0.10.15] (h1.pinyon.org [65.101.20.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by h2.pinyon.org (Postfix) with ESMTPSA id 5138BFF00 for ; Sun, 11 Jun 2017 17:51:36 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1497228696; bh=cku2BkVasK5CyiBUCrgeq0UUYY2W2ynNh02kOVyuxpQ=; h=Subject:To:References:From:Date:In-Reply-To; b=iBpqojz52ZOQo34JZXKWR98++8VSsSB7zm26k5n/VtlCZ/OSVlH7VIbFtY1h5hNJn yqirr4HEyODoc1Tpd2Fm2dh6Mw1tmdaZozavmicE+Qi9qyHNoUHJg9mjagUmVEp8cT YeXRIrjd1IA98v7Ij773GFfl4cZQD/gJ4IXZMEnA= Subject: Re: -O2 flag To: freebsd-questions@freebsd.org 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> From: "Russell L. Carter" Message-ID: Date: Sun, 11 Jun 2017 17:51:36 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1497180132.3245.9.camel@mailman-hosting.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 00:51:40 -0000 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. >> >