[PATCH] rvalue reference implementation for C++0x

Russell Yanofsky russ@yanofsky.org
Sun Mar 11 05:23:00 GMT 2007

On Sat, 2007-03-10 at 18:54 -0800, Andrew Pinski wrote:
> On 3/10/07, Russell Yanofsky <russ@yanofsky.org> wrote:
> > It seems to me like everything you said is already implemented. Rvalue
> > reference types become part of the TYPE_NEXT_REF_TO chain just like
> > other variants of reference types. And build_reference_type() is the
> > front-end wrapper for the build_reference_type_for_mode() function.
> Really I don't think you should be touching middle-end code to do
> support this feature because this is a very specific reference type to
> C++ in the same way lvalues are speficic to the front-ends.

L-value references are already part of middle end code and I don't see
why r-value references should be different. Are there actually other
languages besides C++ which use REFERENCE_TYPE nodes? It is
understandable that you would be put off by presence of new middle-end
functions with the word "rval" in them. But I could have easily called
those functions build_reference_type_1 instead of
build_rval_reference_type, and I could just as as easily remove those
functions entirely, as I proposed to do in my last post. Those are just
adapter functions, a straightforward way of adding a new boolean field
while remaining backward compatible with existing build_reference_type
invocations to minimize the number of extraneous changes included in the

> Also what does C++0x say about the aliasing sets of rvalue reference
> type vs the reference type are they the same or can they be different?
> I think it is better to create a new type in the C++ front-end and
> mirror what is done building reference type but have a hash table
> instead of using TYPE_REFERENCE_TO (really that code should be changed
> to use a hash table instead of an extra field in the type anyways).
> And during gimplification lower the type down to the reference type.

This is mostly greek to me, I'm sorry. I understand the C++ front end
pretty well, but I know next to nothing about gimplification or any of
the lower level stuff. 

From what I know about the front end, talking about using a hash table
instead of a boolean field, and separate node types for r- and l-value
reference types sounds like insanity to me. Except for some isolated
changes to overload resolution and type deduction rules there is no
difference between an r-value reference and a plain old reference in any
of the places references are used in the front end. I can't see any
benefit in trying handle l-value and r-value reference types seperately
and while I can see there being a considerable cost in terms of

-  Russell Yanofsky (PGP ID: 0x5FAA0216)
-  http://russ.yanofsky.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070311/878544c3/attachment.sig>

More information about the Gcc-patches mailing list