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] |
On Sat, 2007-03-10 at 23:23 -0500, Doug Gregor wrote:Jason is saying that it would be better if we could keep *all* of the changes in the C++ front end, and not touch any of the common bits (tree.c, tree.h).
Why would you actually want to do this? References are a C++ only notion, aren't they? By the same logic you would try take references out of the middle end and implement them as pointers or something.
I know
the build_rval stuff is ugly, and I'd like to fix that. But is wrong
with sticking with a simple boolean field in REFERENCE_TYPE nodes?
I mean you are talking about bringing TYPE_NEXT_REF_TO into the front end. TYPE_NEXT_REF_TO is an internal detail of REFERENCE_TYPE nodes currently handled by the middle end, and you want to bring it into the front end, as well as add some kind of ordering assumption to the TYPE_NEXT_REF_TO list. Any way you do this you are going to have some kind of interaction between the front and middle ends. It would make sense to me to want to keep that interaction as simple as possible, and you can't get much simpler than a boolean field.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |