This is the mail archive of the gcc@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: [c++, cxx-reflection] Initial thoughts on type reflection.


On Mon, Mar 10, 2003 at 06:32:09AM +0100, Gabriel Dos Reis wrote:
> 
> There is a category of built-ins called BUILT_IN_FRONTEND, which are
> expanded by the front-ends.  In our case we don't want RTL, still we

Right.  I went with BUILT_IN_NORMAL for this reason.


> 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).

Actually...  I think this is somewhat moot, since none of the builtin
functions can take types as arguments.  Which leaves two options:

1)  Add __builtin_* expressions to the parsers.  One already exists, in
    the form of __builtin_va_arg.  That isn't handled by the BUILT_IN_*
    tags at all:

    /* Expand __builtin_va_arg, which is not really a builtin function, but
       a very special sort of operator.  */

    So, going that route sort of obviates any BUILT_IN_* stuff as far as
    I can tell; the "operators" are handled specially.

2)  Do something else.  My implementations have all gone this route, and
    pay a small price in readability.


> The invariant here is that, the ressult
> of the expansion is still something that conceptually happens at the code
> source level.

Absolutely.  If you can convince people that changing expand_builtin to not
return rtx is a good idea, that'd be great.


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


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