-O2 flag

Russell L. Carter rcarter at pinyon.org
Mon Jun 12 00:51:40 UTC 2017

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.


>> 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.

More information about the freebsd-questions mailing list