This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gimple] assignments to volatile


On Jun 23, 2010, at 6:08 AM, Mark Mitchell wrote:
> Nathan Sidwell wrote:
> 
>> RVCT generated code consistent with my proposal.  Specifically in:
>> some_use_of = volatile_object = value;
>> the volatile object is only written to and not read, regardless of the
>> context of that volatile assignment (be it return expression,
>> conditional expression or serial assignment).
> 
> Good.
> 
>>>   vobj;
>>>   (void) vobj;
>> 
>> Both of these cause a read of vobj in RVCT (and GCC).
> 
> Good.
> 
> If there are no objections within the next 48 hours,

I object.

gcc semantics are carefully designed.  gcc is the standard compiler for much embedded work, C and C++ differ due to the standards organizations, some of those differences are truly unfortunate, but there you go.  If someone wanted to fix gcc, the proper way would be to get the C and C++ committees on the same page, nail it down, or make it a hard error, and remove any latitude and confusion and make them agree.

C++ says:

  All require a modifiable lvalue as their left operand and return an lvalue referring to the left operand.

You can't just willy nilly change this:

int i, j, k;
void foo(int &j) {
  foo(i = k);
}

can sense if you get it right or not.  Add a volatile on i, and you discover, you can't just change this as you see fit, in particular, not in the way you all seem to want, which is just plain wrong.

Further, C says:

  An assignment expression has the value of the left operand after the assignment

Now, this is pretty plain, the value is the left operand.  They choose this wording as they didn't want the return value to be a modifiable lvalue.  I concede there is enough wiggle room here to confuse users and give implementors enough latitude to try and claim they are following the standard, but really, the return value is the valuer of the left operand, if it weren't, the standard would not say it was.  It could have said, the value is the value that was stored in the left operand, or the value is the right operand after conversion to the type of the left operand, or a host of other possibilities.

> then I think we should consider the semantics settled.  I'm not trying to squash
> discussion; if people don't like those semantics, let's discuss.  But, I
> think existing practice should weigh heavily.

This semantic in gcc has been the industry standard for at least 15 years.  If there have been any code written that depend upon this, you break them all.  This breakage is silent, and in the type of code that you really don't want to break in this way.

I object to the change.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]