Path: csiph.com!2.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!buffer1.nntp.ams1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 14 Nov 2016 13:49:49 -0600
From: Gareth Owen <gwowen@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Compiler design in C?
References: <nvsmpq$noi$2@dont-email.me> <o02q7a$oca$1@dont-email.me> <23d0f58e-a17c-4ef7-8db6-9cc5b7bcaf04@googlegroups.com> <o040re$d5a$1@dont-email.me> <9e27a17d-aaab-48e1-9139-95114dea0da6@googlegroups.com> <o05b51$81t$1@dont-email.me> <3121b7be-aca1-44b0-9dc9-6b23611bbfba@googlegroups.com> <o074os$61m$1@dont-email.me> <300e8fda-56cf-476f-9bd7-257791357090@googlegroups.com> <8760nsr02s.fsf@gmail.com> <0dc796fe-911c-4dc0-952a-7b9e3ed54eae@googlegroups.com> <87mvh4kytv.fsf@bsb.me.uk> <7f59dd53-a2fd-4e61-85b9-308790eeab7d@googlegroups.com> <877f87llzn.fsf@bsb.me.uk> <7309d801-64fc-4d2b-961e-1e8b50f11389@googlegroups.com> <878tsn2e8z.fsf@gmail.com> <65a37d5b-1c93-41ad-95f4-321c05397d43@googlegroups.com> <87vavqh6zf.fsf@gmail.com> <f4ce9545-c5e7-4db8-8e46-dcaafa2bbd01@googlegroups.com> <874m39ykb4.fsf@gmail.com> <5c07d760-4246-4ff1-b34c-1a32eb69d49b@googlegroups.com>
Date: Mon, 14 Nov 2016 19:49:48 +0000
Message-ID: <87d1hx6dur.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:FX04ROWkwPuYBdmgQ2KGSb6hdd4=
MIME-Version: 1.0
Content-Type: text/plain
Lines: 22
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9dSTDY5Px+UhITsQNLCwrq4xXC9TvcLWBZvzNdv/ae0MWBFfeZyOsU2/ngfkh/EGdHk2ofhk+rWpsn3!mSps7I2Q3hxCyFDz1mKdNHRMp+SqWrGnsj2q7NZQYBeoa/7uaLfWuWJZbjjWvz9wT2Wi
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2766
Xref: csiph.com comp.lang.c:96565

supercat@casperkitty.com writes:

> The behavior of a program which stores 3 in one temporary location and 4
> in another, reads the contents of those locations, adds them, and prints
> the sum, would be indistinguishable from that of a program which simply
> outputs 7.

This is true of every optimisation against which you have been ranting.
That's essentially the *definition* in the standard, that you seem to
have a problem with.

Now you're using it to say "No, these optimisations are OK, even though
the program seems to have loads/stores I'm perfectly OK for *these*
loads and stores not to happen."

Again, what is it about the elision/rearrangement of these loads/stores
that's acceptable to you, that isn't the case for the others?

How does *your* "as if" rule differ from the Standard's version?

I genuinely cannot discern what it is that you wish to codify.
From the word salad that followed, I don't think you're sure either.