[9fans] make passive aggressive gcc

[9fans] make passive aggressive gcc

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 964 bytes --]

Re: [9fans] make passive aggressive gcc

[Ethan Grammatikidis]

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

--
Developing the austere intellectual discipline of keeping things
sufficiently simple is in this environment a formidable challenge,
both technically and educationally.
 -- Dijstraka, EWD898, 1984

Re: [9fans] make passive aggressive gcc

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Ugh, I know. It caused Judy arrays to segfault a lot.

>From my personal experience, Clang does *not* have this problem.


On June 15, 2015 3:21:56 AM CDT, 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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1496 bytes --]

Re: [9fans] make passive aggressive gcc

[Siarhei Zirukin]

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.

Re: [9fans] make passive aggressive gcc

[Ethan Grammatikidis]

On Mon, 15 Jun 2015 16:56:28 +0200
Siarhei Zirukin <ftrvxmtrx@gmail.com> wrote:

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

So -O0 hasn't improved since 2008 then. Time to switch to clang, I
guess.

--
Developing the austere intellectual discipline of keeping things
sufficiently simple is in this environment a formidable challenge,
both technically and educationally.
 -- Dijstraka, EWD898, 1984

Re: [9fans] make passive aggressive gcc

[dexen deVries]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

>
> 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 <ftrvxmtrx@gmail.com>
wrote:

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

[-- Attachment #2: Type: text/html, Size: 3018 bytes --]

[9fans] Wildly off-topic

[Andrew Simmons]

As the subject line says, wildly off-topic. But some-one here might know the answer, and it’s been bothering me.

Such are my failings, I’ve been watching the second series of “Halt and Catch Fire” in order to catch up with what the kids are up to these days. In the second episode one of the characters opens what looks like a copy of K&R first edition, but the cover is blue. I thought that the colour correction on my TV might be deceiving me, or possibly the vertical hold was on the fritz, but he did it again in the third episode, and the cover was still blue.

So my question is, did there ever exist an edition of K&R in that colour scheme, or is gcc to blame for the inaccuracy?

Re: [9fans] Wildly off-topic

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

It's always GCC.

On Mon, Jun 15, 2015 at 6:06 PM, Andrew Simmons <kodogo@gmail.com> wrote:

> As the subject line says, wildly off-topic. But some-one here might know
> the answer, and it’s been bothering me.
>
> Such are my failings, I’ve been watching the second series of “Halt and
> Catch Fire” in order to catch up with what the kids are up to these days.
> In the second episode one of the characters opens what looks like a copy of
> K&R first edition, but the cover is blue. I thought that the colour
> correction on my TV might be deceiving me, or possibly the vertical hold
> was on the fritz, but he did it again in the third episode, and the cover
> was still blue.
>
> So my question is, did there ever exist an edition of K&R in that colour
> scheme, or is gcc to blame for the inaccuracy?
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

[-- Attachment #2: Type: text/html, Size: 1598 bytes --]

Re: [9fans] Wildly off-topic

[Bakul Shah]

On Tue, 16 Jun 2015 11:06:48 +1200 Andrew Simmons <kodogo@gmail.com> wrote:
> As the subject line says, wildly off-topic. But some-one here might know =
> the answer, and it=E2=80=99s been bothering me.
>
> Such are my failings, I=E2=80=99ve been watching the second series of =
> =E2=80=9CHalt and Catch Fire=E2=80=9D in order to catch up with what the =
> kids are up to these days. In the second episode one of the characters =
> opens what looks like a copy of K&R first edition, but the cover is =
> blue. I thought that the colour correction on my TV might be deceiving =
> me, or possibly the vertical hold was on the fritz, but he did it again =
> in the third episode, and the cover was still blue.
>
> So my question is, did there ever exist an edition of K&R in that colour =
> scheme, or is gcc to blame for the inaccuracy?=

Amazon trade ins of The C programming Language shows a cyan
blue cover -- it says "Eastern Economic Edition" and it is the
second edition.

http://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/8120305965/ref=sr_1_2?s=tradein-aps&srs=9187220011&ie=UTF8&qid=1434409938&sr=8-2&keywords=the+c+programming+language

Re: [9fans] Wildly off-topic

[Kurt H Maier]

Quoting Andrew Simmons <kodogo@gmail.com>:

> So my question is, did there ever exist an edition of K&R in that

Quoting Andrew Simmons <kodogo@gmail.com>:

> Thanks, but it seems as if that web page is for the 2nd edition.

ok, still yes.

The linked page is for all editions.

khm

Re: [9fans] Wildly off-topic

[Ramakrishnan Muthukrishnan]

On Tue, Jun 16, 2015, at 04:52 AM, Bakul Shah wrote:
> On Tue, 16 Jun 2015 11:06:48 +1200 Andrew Simmons <kodogo@gmail.com>
> wrote:
> > As the subject line says, wildly off-topic. But some-one here might know =
> > the answer, and it=E2=80=99s been bothering me.
> >
> > Such are my failings, I=E2=80=99ve been watching the second series of =
> > =E2=80=9CHalt and Catch Fire=E2=80=9D in order to catch up with what the =
> > kids are up to these days. In the second episode one of the characters =
> > opens what looks like a copy of K&R first edition, but the cover is =
> > blue. I thought that the colour correction on my TV might be deceiving =
> > me, or possibly the vertical hold was on the fritz, but he did it again =
> > in the third episode, and the cover was still blue.
> >
> > So my question is, did there ever exist an edition of K&R in that colour =
> > scheme, or is gcc to blame for the inaccuracy?=
>
> Amazon trade ins of The C programming Language shows a cyan
> blue cover -- it says "Eastern Economic Edition" and it is the
> second edition.

Yes, I can confirm that. It is sold here in India. It used to be the
same white cover as the international edition (my copy from 1993,
eastern economy edition, has a white cover).

--
  Ramakrishnan