Bogus mayhaps. Whatever the issue, it's been there a while because previous
versions fail as well. Having spent the first 25-30 years of my career in
assembly language, I completely understand "optimization" by a compiler;
it's a method used to attempt compensation for inherent inefficiencies in
the language and/or compiler itself. The very existence of something like
Valgrind (which I am enjoying very much, thanks for the tip guys!) speaks
much about the language, IMHO.

Add the fact that you have a processor instruction set which encourages and
proliferates the use of arbitrary delimiters a la repne/repe/etc rather
than enforcing length based operations is problematic and, where I come
from, just bad karma.

But I digress. I've always considered compiler "optimizations" to be a form
of witchcraft and thus, suspect. The code is fairly complex, multi-threaded
SMP capable, and as it performs hw emulation, also traps faults by
necessity, which severely increases the PITA factor in debugging/diagnosis.
The lazy programmer in me was hoping to find a "doh, you're an idiot" or
stupid oversight I had missed from the folks here, but alas, like the auto
problem I know will be a bear to fix, I must pull out the ramps and open
the hood.

Nonetheless, my venture has not been fully in vain, I've got some new tools
and options to try, thanks to many of the folks here.

Cheers!

SWS



On Apr 22, 2016 11:47 AM, "Adam Borowski" <kilobyte@???> wrote:

> On Fri, Apr 22, 2016 at 10:27:16AM +0200, parazyd wrote:
> > On Thu, 21 Apr 2016, Steven W. Scott wrote:
> > >    Just curious, anyone else getting segfaults after compiling with
> gcc -O3
> > >    optimization flag on alpha 4? Same system, same code, same flags
> work ok
> > >    on Wheezy. If I back down to -O2 no problems.

> > >

> > >    I'm blaming gcc, but I was interested if anyone else had a similar
> > >    experience or insight as to what might be the issue.

> >
> > Do you actually understand how optimization works? The bigger the level,
> > the more unsafe code you get, like you just got segfaults. Depending on
> > the program, one will take some max. level of optimization, but any
> > higher and it will break, like yours did.
>
> While GCC is not totally bug-free and thus optimization errors do happen,
> in
> 99.9% cases it's a bug in the code you're compiling.
>
> Using any of canned optimization levels other than -Ofast, does not change
> the behaviour of any standards-compliant program. Unless you do something
> that won't be kept on a different architecture/different compiler, such as
> converting a pointer to int and using it as a non-opaque value, you will
> get
> the same result, just (hopefully) faster.
>
> So sorry, your program is likely bogus. There's a lot of tools that can
> help finding such errors, such as valgrind or -fsanitize=*.
>
> > Note how many more warnings you get on compilation as you get higher in
> > optimization level.
>
> That's a good thing -- the compiler analyzes the code deeper and thus is
> able to spot more suspicious things.
>
> --
> A tit a day keeps the vet away.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>