"as-is" rule

"as-is" rule

[Eli Zaretskii]

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

Re: "as-is" rule

[Andreas Schwab]

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."

Re: "as-is" rule

[Stefan Monnier]

> 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

Re: "as-is" rule

[Eli Zaretskii]

> 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.

Re: "as-is" rule

[Samuel Bronson]

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?

Re: "as-is" rule

[Stefan Monnier]

>> 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