On Sat, Jun 11, 2011 at 7:45 PM, Mike Stump <mikest...@comcast.net> wrote: > On Jun 10, 2011, at 7:20 AM, Richard Guenther wrote: >> On Fri, 10 Jun 2011, Jason Merrill wrote: >> >>> On 06/10/2011 10:03 AM, Richard Guenther wrote: >>>>>> *((volatile int *)&a[0] + 1) >>>>> >>>>> It would be correct to fold it to >>>>> >>>>> VIEW_CONVERT_EXPR<volatile int,a[1]> >>>> >>>> No, it wouldn't be correct. It isn't correct to fold it to an array-ref >>>> that isn't volatile. >>> >>> Hmm? The C expression produces a volatile int lvalue referring to the >>> second >>> element of a, as does the VIEW_CONVERT_EXPR. They seem equivalent to me. >> >> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example >> would turn the above to (volatile int) a[1]). > > Curious. We have built up a built-in infrastructure that allows for lvalue > register references. I noticed that for vector types, vectors with different > type names but the same in every other respect come out different, and a > VIEW_CONVERT_EXPR is placed on it to get the types to match. Presently I'm > treating VIEW_CONVERT_EXPR as an lvalue. For me not to, I'd need either for > the same type to be used, or, for another conversion node to be used that can > preserve the lvalueness of registers. > > Now, if people want to know why, lvalue for registers, it is to support > in/out and output only parameters to built-ins. > > Thoughts?
In almost all cases(*) the need for a lvalue VIEW_CONVERT_EXPR can be avoided by moving the VIEW_CONVERT_EXPR to the rvalue assigned too it. Remember that VIEW_CONVERT_EXPR always conver the full object and are not allowed to change sizes. So, do you have an example? Richard. (*) Ada uses lvalue component-refs on VIEW_CONVERT_EXPRs of aggregate types. While I don't like it too much it's probably not too convenient (even if it is always possible) to move these to the RHS of assignments.
