On Mon, Jun 15, 2015 at 3:41 PM, Ethan Grammatikidis
<eekee57@fastmail.fm> wrote:
> On Mon, 15 Jun 2015 09:21:56 +0100
> Charles Forsyth <charles.forsyth@gmail.com> wrote:
>
>> If you're using gcc 4.8.2 to compile ... anything, really ... but certainly
>> Plan 9 or Inferno components,
>> and those use for loops with arrays, be sure to include the compilation
>> options
>> -fno-strict-aliasing\
>> -fno-aggressive-loop-optimizations\
>> and it will save you some time and effort.
>> It will save compilation time (not that you'll notice with that sluggard)
>> because it won't
>> fuss even more with your program, and it will save effort, because you
>> won't have
>> to debug simple loops that have bounds changed, are removed completely, or
>> otherwise wrecked.
>> You can find discussions of it elsewhere (which is how I found compiler
>> options to stop it).
>> I'd forgotten all about it until it surfaced again.
>
> Thanks. Reminds me I liked gcc when it applied very few optimizations.
> I guess it must have been focused on machine-specific optimizations
> back in 2007/2008. I had a cpu newer than gcc had support for, and
> compilation was actually quick. Anyone know if -O0 is a reasonable
> option these days? (I mean tested well enough to be reasonably
> bug-free.)

I've recenetly seen a few examples where -O0 would produce a
segfaulting executable, while any other -Ox would work fine.
Also, I don't know what gcc authors are smoking, but "strcpy(tmp,
"what.");" will be compiled to a few mov instructions with -O0, while
-Os still has a call to strcpy, just the way it *should* always be,
imho. I just checked this once again (gcc-4.8.4) and it still applies.