[Top][All Lists]
[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.