emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "as-is" rule


From: Eli Zaretskii
Subject: Re: "as-is" rule
Date: Wed, 30 Nov 2011 19:02:27 +0200

> From: Stefan Monnier <address@hidden>
> Date: Wed, 30 Nov 2011 09:20:27 -0500
> Cc: address@hidden
> 
> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]