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 09:20:27 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1322662848 29954 80.91.229.12 (30 Nov 2011 14:20:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2011 14:20:48 +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 15:20:43 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 1RVl1e-0006UR-Kj for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2011 15:20:42 +0100 Original-Received: from localhost ([::1]:51264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVl1e-0004BP-0u for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2011 09:20:42 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVl1X-0004B9-ST for emacs-devel@gnu.org; Wed, 30 Nov 2011 09:20:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RVl1S-00077q-4i for emacs-devel@gnu.org; Wed, 30 Nov 2011 09:20:35 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVl1S-00077X-1K; Wed, 30 Nov 2011 09:20:30 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pAUEKSNN004339; Wed, 30 Nov 2011 09:20:28 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E9C5D593DC; Wed, 30 Nov 2011 09:20:27 -0500 (EST) In-Reply-To: (Eli Zaretskii's message of "Wed, 30 Nov 2011 07:35:16 -0500") 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 <706558> : uri <1019110> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:146363 Archived-At: > See bug #10164: I've been hit by code re-ordering under the "as-is" rule. > I asked before, but no one replied: is there a place where I can read > the description of conditions that _disallow_ such reordering? I think you've hit a bug in gcc in this case: "e1 || e2" should not evaluate e2 if e1 evaluates to non-0. The as-is rule allows gcc to run any part of e2 (or any other code for that matter) at any time it feels like, but only if you can't tell the difference, and in this case we can definitely tell the difference. Of course, in the world of C it's pretty common for such problems to be due not really to a compiler bug but to an "unspecified", "implementation defined" or "undefined" part of the language semantics giving more freedom to the compiler than the programmer expects. But I don't think this can be the case here (and I can't think of any reason why the C language would allow the problem for "e1 || e2" but not for "if (!e1) e2", since both seem to have just as much of a sequencing point between the two expresssions). BTW, I don't like this "#if XASSERTS" and would hence much prefer xassert ((row->enabled_p && !row->mode_line_p) ? verify_row_hash (row) : 1); Stefan