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: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)))


On Sun, Jun 12, 2011 at 12:59 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Sat, Jun 11, 2011 at 10:01 PM, Jason Merrill <jason@redhat.com> wrote:
>> On 06/10/2011 10:20 AM, Richard Guenther wrote:
>>>
>>> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example
>>> would turn the above to (volatile int) a[1]).
>>
>> The gimplifier seems to consider it an lvalue: gimplify_expr uses
>> gimplify_compound_lval for it, and gimplify_addr_expr handles taking its
>> address. ?And get_inner_reference handles it. ?So I think fold should be
>> changed, and we should clarify that VIEW_CONVERT_EXPR is an lvalue.
>>
>> If not, we need a new tree code for treating an lvalue as an lvalue of a
>> different type without having to take its address; that's what I thought
>> VIEW_CONVERT_EXPR was for.

Btw, see tree.def which says

/* Represents viewing something of one type as being of a second type.
   This corresponds to an "Unchecked Conversion" in Ada and roughly to
   the idiom *(type2 *)&X in C.  The only operand is the value to be
   viewed as being of another type.  It is undefined if the type of the
   input and of the expression have different sizes.

   This code may also be used within the LHS of a MODIFY_EXPR, in which
   case no actual data motion may occur.  TREE_ADDRESSABLE will be set in
   this case and GCC must abort if it could not do the operation without
   generating insns.  */
DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1)

> The please provide a specification on what a VIEW_CONVERT_EXPR does
> to type-based alias analysis. ?We are trying to avoid that by the rvalue rule.
> Also you can always avoid VIEW_CONVERT_EXPRs for lvalues by simply
> moving the conversion to the rvalue side.
>
> Yes, we do handle lvalue VIEW_CONVERT_EXPRs, but that is for Ada
> which uses it for aggregates. ?I don't want us to add more lvalue
> VIEW_CONVERT_EXPR
> cases, especially not for register types.
>
> Richard.
>
>> Jason
>>
>


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