From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20150615144155.7bbe6219@lahti.ethan.home> Date: Mon, 15 Jun 2015 18:05:32 +0200 Message-ID: From: dexen deVries To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c23f64a246e1051890a001 Subject: Re: [9fans] make passive aggressive gcc Topicbox-Message-UUID: 58b64c54-ead9-11e9-9d60-3106f5b1d025 --001a11c23f64a246e1051890a001 Content-Type: text/plain; charset=UTF-8 > > 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. not that it's any excuse, but -fno-builtin helps. On Mon, Jun 15, 2015 at 4:56 PM, Siarhei Zirukin wrote: > On Mon, Jun 15, 2015 at 3:41 PM, Ethan Grammatikidis > wrote: > > On Mon, 15 Jun 2015 09:21:56 +0100 > > Charles Forsyth 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. > > --001a11c23f64a246e1051890a001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don= 9;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.

not that it's any excuse, but -fn= o-builtin helps.

On Mon, Jun 15, 2015 at 4:56 PM, Siarhei Zirukin <ftrvx= mtrx@gmail.com> wrote:
On Mon, Jun 15, 2015 at 3:41 PM, Ethan = Grammatikidis
<eekee57@fastmail.fm> wrot= e:
> On Mon, 15 Jun 2015 09:21:56 +0100
> Charles Forsyth <charl= es.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 compil= ation
>> 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 tha= t 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 comple= tely, or
>> otherwise wrecked.
>> You can find discussions of it elsewhere (which is how I found com= piler
>> 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,<= br> "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.


--001a11c23f64a246e1051890a001--