This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++PATCH: va_arg & aggr type
- To: nathan at cs dot bris dot ac dot uk
- Subject: Re: C++PATCH: va_arg & aggr type
- From: Jason Merrill <jason at cygnus dot com>
- Date: 11 Oct 1999 13:17:57 -0700
- Cc: egcs-patches at egcs dot cygnus dot com, mark at codesourcery dot com, Franz dot Sirl-kernel at lauterbach dot com, rth at cygnus dot com
- References: <37F8C075.AE414A9E@acm.org> <19991004121423P.mitchell@codesourcery.com> <37F9B7D0.39A4D2FB@acm.org> <u9zoxxwvwo.fsf@yorick.cygnus.com> <3801A198.FB066AC2@acm.org>
>>>>> Nathan Sidwell <nathan@acm.org> writes:
> Ok, I was vague in what I meant, and used a scalar example, when I
> should've used an aggr. What I meant to convey was that a tree
> representing
> const struct X *xp = &va_arg (args, struct X);
> would be better than one representing
> struct X _tmp = va_arg (args, struct X);
> const struct X *xp = &_tmp;
> which has the copy
Note that the semantics are different for these two; the second one
guarantees that *xp will be valid while xp is in scope, while the first one
points xp to a temporary which goes away at the end of the statement. I
think there's probably a better way to avoid the copy, but I don't know the
new va_arg code at all; maybe return a TARGET_EXPR for aggregate values?
>> > *************** lvalue_p_1 (ref, treat_class_rvalues_as_
>> > *** 142,147 ****
>> > --- 142,148 ----
>> > treat_class_rvalues_as_lvalues);
>> > case TARGET_EXPR:
>> > + case VA_ARG_EXPR:
>> > return treat_class_rvalues_as_lvalues ? clk_class : clk_none;
>> We can get VA_ARG_EXPRs for non-class types, can't we?
> Yes, but we only need to treat aggr things as lvalues so that we can
> copy them. We don't want va_arg to give an lvalue do we? But, in that
> case we need to check that TREE_TYPE (ref) is an aggr type, so I attach
> the an updated patch. (This does mean that I don't understand why
> TARGET_EXPR doesn't do such a check.)
Probably an oversight; feel free to change it, too.
> This one ok?
Yes.
Jason