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?
