* "as-is" rule @ 2011-11-30 12:35 Eli Zaretskii 2011-11-30 13:57 ` Andreas Schwab 2011-11-30 14:20 ` Stefan Monnier 0 siblings, 2 replies; 6+ messages in thread From: Eli Zaretskii @ 2011-11-30 12:35 UTC (permalink / raw) To: emacs-devel 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? TIA ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "as-is" rule 2011-11-30 12:35 "as-is" rule Eli Zaretskii @ 2011-11-30 13:57 ` Andreas Schwab 2011-11-30 14:20 ` Stefan Monnier 1 sibling, 0 replies; 6+ messages in thread From: Andreas Schwab @ 2011-11-30 13:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > See bug #10164: I've been hit by code re-ordering under the "as-is" > rule. Definitely not. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "as-is" rule 2011-11-30 12:35 "as-is" rule Eli Zaretskii 2011-11-30 13:57 ` Andreas Schwab @ 2011-11-30 14:20 ` Stefan Monnier 2011-11-30 17:02 ` Eli Zaretskii 2011-11-30 18:44 ` Samuel Bronson 1 sibling, 2 replies; 6+ messages in thread From: Stefan Monnier @ 2011-11-30 14:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "as-is" rule 2011-11-30 14:20 ` Stefan Monnier @ 2011-11-30 17:02 ` Eli Zaretskii 2011-11-30 19:09 ` Stefan Monnier 2011-11-30 18:44 ` Samuel Bronson 1 sibling, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2011-11-30 17:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Date: Wed, 30 Nov 2011 09:20:27 -0500 > Cc: emacs-devel@gnu.org > > > 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. This is what I always knew: that `e1 || e2 || e3' are evaluated left to right. But I understand the "as-is" rule relaxed that. Or maybe I'm confused (which is why I asked the question in the first place). > 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. How do you mean "we can tell the difference"? In general, if the "left-to-right evaluation" rule is no longer a must, e1, e2, and e3 could have been evaluated in _any_ order, and then if one of them is non-zero, the condition holds. No? Again, I'm utterly confused about this issue. If someone can explain or point me to an existing explanation, I'd be grateful. > 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); If we are dealing with a compiler bug, how can we be sure this expression will not hit the same bug? Anyway, I eventually removed the assertion altogether, so this is a moot point now. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "as-is" rule 2011-11-30 17:02 ` Eli Zaretskii @ 2011-11-30 19:09 ` Stefan Monnier 0 siblings, 0 replies; 6+ messages in thread From: Stefan Monnier @ 2011-11-30 19:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "as-is" rule 2011-11-30 14:20 ` Stefan Monnier 2011-11-30 17:02 ` Eli Zaretskii @ 2011-11-30 18:44 ` Samuel Bronson 1 sibling, 0 replies; 6+ messages in thread From: Samuel Bronson @ 2011-11-30 18:44 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel On Wed, Nov 30, 2011 at 9:20 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> 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. Not to nitpick, but ... (oh, who am I kidding -- yes, to nitpick!) ... isn't that called the "as-if" rule? ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-11-30 19:09 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-30 12:35 "as-is" rule Eli Zaretskii 2011-11-30 13:57 ` Andreas Schwab 2011-11-30 14:20 ` Stefan Monnier 2011-11-30 17:02 ` Eli Zaretskii 2011-11-30 19:09 ` Stefan Monnier 2011-11-30 18:44 ` Samuel Bronson
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.