Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: rhel 7 and kforth Date: Fri, 17 Apr 2015 10:33:46 -0700 Organization: A noiseless patient Spider Lines: 51 Message-ID: <87d232wtfp.fsf@jester.gateway.pace.com> References: <6b95db78-ff4c-42aa-9680-7e4e588f61a4@googlegroups.com> <29c7eb53-229e-40a4-9bad-0d14e953ebc3@googlegroups.com> <87f18d43-a91e-4ae7-b98a-2cf4b7227c47@googlegroups.com> <87y4lrwpfo.fsf@jester.gateway.pace.com> <87twwfwlm2.fsf@jester.gateway.pace.com> <87pp73wi24.fsf@jester.gateway.pace.com> <87a8y695hs.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="bda44be170c76b3ef6d23fecd204a8fa"; logging-data="15410"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18k2Ur46baTRLoSSX7YeYUr" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:2Wmn8tRl/sYLG7INZPpmf9BCdw4= sha1:MCHrqTvxJ9RlzdAikOXPVRBRMCw= Xref: csiph.com comp.lang.forth:38285 krishna.myneni@ccreweb.org writes: > I'm not claiming there is universal practice for compiling this > expression. In my experience with C compilers, I haven't seen any > exceptions. You mean exceptions with a[i]=i++? How many compilers did you try that with? If you mean exceptions with *sp-- = *(sp + 1), obviously you did just encounter a different compilation than what you expected. > Obviously, I'm peeved at having my code unnecessarily broken by poor > choices made by the compiler. Whether it was a poor choice is necessarily somewhat subjective. The compiler writers take the view that the good-vs-poor decision was made during the standardization process and if it was a poor choice, the standard wouldn't have allowed it. So when they're left with a set of options neutrally allowed by the standard, they naturally pick the one that generates the fastest code that they can. If they generated different (slower) code earlier, that only means last year's optimizers were less advanced than this year's. > But, the actual fix is relatively simple. I can't see that the fix was > justified by the standard. Did you micro-benchmark both versions? If the "broken" code was faster, that is the justification. > The standard could have stated that the expression, "a[i] = i++;" uses > the instantaneous value of i just before the expression, for every > reference of i. But, perhaps this leads to consistency problems with > other expressions. I dunno about consistency problems but I can tell you from having gotten in arguments with those guys, the #1 thing they cared about was fast code, and they opted for it over an "err on the side of caution" approach. I'd agree that this has caused problems that are being recognized somewhat in hindsight (one reason I'm terrified of anything written in C today). But, the choices made back then were at least arguably a sane fit for the knowledge and priorities that existed at the time. GCC has various command line options to disable some of the more surprising optimizations and I like Regehr's proposal of a less aggressive dialect, that could be enabled by a single option or even made the default. >> > Yes, I see the compiler warnings for both examples with -Wall It's probably worth compiling the whole program with -Wall and checking all the messages for other problems. -Wall has apparently gotten pretty good.