Re: m68k gcc/egcs question

Zoltan Kocsi <>
1 Oct 1999 10:10:40 -0400

          From comp.compilers

Related articles
m68k gcc/egcs question (Zoltan Kocsi) (1999-09-20)
Re: m68k gcc/egcs question (David Williams) (1999-09-24)
Re: m68k gcc/egcs question (1999-09-24)
Re: m68k gcc/egcs question (James Jones) (1999-09-27)
Re: m68k gcc/egcs question (1999-09-28)
Re: m68k gcc/egcs question (Zalman Stern) (1999-10-01)
Re: m68k gcc/egcs question (Zoltan Kocsi) (1999-10-01)
Re: m68k gcc/egcs question (Zalman Stern) (1999-10-03)
Re: m68k gcc/egcs question (Graham Murray) (1999-10-03)
| List of all articles for this month |

From: Zoltan Kocsi <>
Newsgroups: comp.sys.m68k,comp.compilers
Date: 1 Oct 1999 10:10:40 -0400
Organization: Bendor Research Pty. Ltd.
References: 99-09-078 99-09-103
Keywords: C++ (Mike Stump) writes:

> a=b=c means fetch c, store into b, fetch b, store into a. It does not
> mean fetch c, and store into both a and b.

Yes, reading the exact wording indeed means that.

> Let me quote from ANSI C++:
> 5.17 Assignment operators [expr.ass]
> 1 There are several assignment operators, all of which group right-to-
> left. All require a modifiable lvalue as their left operand, and the
> type of an assignment expression is that of its left operand.

So far it is simple and clear.

> The
> result of the assignment operation is the value stored in the left
> operand after the assignment has taken place; the result is an lvalue.

As you have stated, it says that the result is an lvalue, therefore it
must be a reference to the left hand storage rather than its content

This will of course turn

    a = b = c;

as you've said to

    b = c;
    a = b;

On the other hand, what if we have pointers ?

    *a = *b = *c;

should it be turned to

      *b = *c;
      *a = *b;

in which case, if b itself is volatile it should result to a re-read of b.
Alternatively, the *a = *b = *c; can be transformed to

      non_volatile typeof( b ) temp;
      temp = b;
      *temp = *c;
      *a = *temp;

which, incidently, is what GCC does.

> No, this is not a dangerous assumption. The asumption is that you
> know the rules that gcc uses for volatile.

OK, I deserved that.

> Also if someone can state what c9x says about this, that would be
> great.

It says this:

    An assignment operator stores a value in the object designated by
    the left operand. An assignment expression has the value of the left
    operand after the assignment, but is not an lvalue.

(Now this is interesting - it is actually a change from what you've quoted
and makes the whole issue less clear.)

    The type of an assignment expression is the type of the left operand
    unless the left operand has qualified type, in which case it is the
    unqualified version of the type of the left operand. The side effect
    of updating the stored value of the left operand shall occur between
    the previous and the next sequence point.

> I think that the language standards should answer these types
> of questions in a complete and unambiguous way.

It should, shouldn't it ...

> I am sorry that they don't. Petition your languages standards to
> do this.

I'll try :-)


| Zoltan Kocsi | I don't believe in miracles |
| Bendor Research Pty. Ltd. | but I rely on them. |

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.