Assignment operator

[Zoltan Kocsi <zoltan at bendor dot com dot au>]

I hope I'm at the right place finally to seek some help.

gcc (and egcs) for m68k targets (and probably for others too) when
an assignemnt operator has a volatile left hand side and the value 
of the assignment expression is further used, generate a re-fetch 
of the left hand operand.

That is:

  volatile int a, b, c;
  a = b = c = 0;
  
will end up as

  clear c
  load c
  store b
  load b
  store a
  
Similarly, when copying strings using the while ( *a++ = *b++ );
idiom, when 'a' is a volatile char *, the code generated is:

  loop:
    move.b (a0)+,(a1)
	tst.b  (a1)+
	bne loop
	
(egcs actually generates this code even when 'a' is *not* volatile *)

I believe that this interpretation is wrong, more precisely, 
counter-intuitive and thus dangerous. In case of 'normal' memory, of
course, it doesn't matter (although the code is less efficient) but
with *really* volatile objects (such as memory mapped HW registers) 
this interpretation changes code behaviour significantly compared to
that of the non-volatile case. (I have arguments for the counter-
intuitiveness of the current interpretation, I just don't want to go
into that in this post.)

I raised my concerns on various newsgroups and I was advised that gcc 
must do that because that's what the standard says. 
I then contacted the standard committee, suggesting a change in the 
wording of the assignment operator. They replied me that the standard 
does *not* require a re-fetch of the LHS even if it was volatile, 
although it permits it. They also said that they deliberately left 
that slack in the standard.

In the light of the above, would that be a possibility that the
compiler behaviour could be changed (with a command line flag) so that 
the value of an assignment can be either the value of the left hand
side read back (this is the current interpretation) or the value that 
is written to the left hand side - thus making assignemnt to behave
identically for volatile/non-volatile LHS and avoiding all the
possible misinterpretation traps.

Thank You,

Regards,

Zoltan