From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: "as-is" rule Date: Wed, 30 Nov 2011 14:09:51 -0500 Message-ID: References: <837h2h5ysc.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1322680215 6824 80.91.229.12 (30 Nov 2011 19:10:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2011 19:10:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 20:10:10 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RVpXl-0002JA-LN for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2011 20:10:09 +0100 Original-Received: from localhost ([::1]:42363 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVpXk-0003IW-0r for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2011 14:10:08 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVpXb-0003FI-Bc for emacs-devel@gnu.org; Wed, 30 Nov 2011 14:10:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RVpXV-0002xP-MA for emacs-devel@gnu.org; Wed, 30 Nov 2011 14:09:59 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVpXV-0002wp-GA; Wed, 30 Nov 2011 14:09:53 -0500 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pAUJ9p27022047; Wed, 30 Nov 2011 14:09:51 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 8816813008C; Wed, 30 Nov 2011 14:09:51 -0500 (EST) In-Reply-To: <837h2h5ysc.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Nov 2011 19:02:27 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4057=0 X-NAI-Spam-Version: 2.2.0.9286 : core <4057> : streams <706621> : uri <1019290> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146370 Archived-At: >> I think you've hit a bug in gcc in this case: "e1 || e2" should not >> evaluate e2 if e1 evaluates to non-0. > This is what I always knew: that `e1 || e2 || e3' are evaluated left > to right. But I understand the "as-is" rule relaxed that. No, it did not (and yes Samuel, it's "as-if", not "as-is", sorry). All the "as-if" rule says is that the assembly code may do anything it likes as long as the result agrees with some interpretation of the semantics. There's a lot of noise around this, but in the end it's mostly irrelevant, all it says is: don't presume what kind of assembly will be generated from the source code. All programming languages admit the "as-if" rule and other than C none bother to mention it. C is special only because it has a "low-level" history and feel which makes many people assume many things which the semantics does not guarantee (e.g. ((x-1)+1) may be different from x if x is a pointer to the beginning of an object, since x-1 is undefined (or was it "unspecified"?) in this case). But the C semantics really does guarantee that "e1 || e2" only evaluates e2 if e1 evaluates to 0, so the "as-if" rule is not the problem. >> xassert ((row->enabled_p && !row->mode_line_p) >> ? verify_row_hash (row) : 1); > If we are dealing with a compiler bug, how can we be sure this > expression will not hit the same bug? We can't. > Anyway, I eventually removed the assertion altogether, so this is a > moot point now. Thanks, Stefan