This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [c++, cxx-reflection] Initial thoughts on type reflection.
On Mon, Mar 10, 2003 at 07:07:35AM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <phil at jaj dot com> writes:
>
> | > want them to me marked BUILT_IN_FRONT_END. Our built-ins will be
> | > expanded by the front-end (into a tree or GIMPLE or whatever it gets
> | > called by the time we merge).
[...]
> | So, going that route sort of obviates any BUILT_IN_* stuff as far as
> | I can tell; the "operators" are handled specially.
>
> Whether you call it "operator" or built-in that takes a type-id does
> not change anything fundamental at all.
I think we're talking past each other. My point here is:
- If it's a builtin operator (or whatever) that takes a type, then we
cannot use builtins.def and the BUILT_IN_* enums directly. At all.
Or at least not without major reworking.
Conversely,
- If we use builtins.def and BUILT_IN_* for the direct handling, then we
are stuck with what __builtin_classify_type does: take a value and then
guess the type. Clearly nobody wants this.
Note I say "directly". I'll expand on this later, being rushed for time
right now.
> | Absolutely. If you can convince people that changing expand_builtin to not
> | return rtx is a good idea, that'd be great.
>
> Well, my goal isn't to conince people that they should not return rtx;
> in fact, I want them to conceive room for something that is not rtx :-)
We just said the same thing. :-) I'll watch my grammar more closely.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams