On Wed, Jun 20, 2007 at 10:47:00AM -0700, Mark Mitchell wrote: > Michael Meissner wrote: > > > I think a gradual approach is the right way. I think this can be done in > > the > > stage 2 time frame, but it could be pushed to gcc 4.4 (but we will have the > > same problem as we have now). The way I see it, the steps would be: > > > > 1) Add the basic infrastructure, iterator macros, stdarg_p, prototype_p, > > etc. to the tree. > > > > 2) Change the back ends, 1 by 1 to use the new infrastructure support. > > > > 3) Change the front ends, 1 by 1 to use the new infrastructure support. > > > > 4) Remove/rename TYPE_ARG_TYPES, and fix any random breakage. > > > > 5) Switch the infrastructure underneath to use vectors. > > > > Until #4, you are only changing one thing at a time, and can easily verify > > that > > the change works. > > Yes, I think that this is a good plan. We can evaluate whether #4 has > to happen on a branch and wait for 4.4 when we get to it. But, 1, 2, 3 > I think are non-controversial, and can go into mainline in real time, > which is nice. > > Thanks,
One minor note, one usage that I didn't notice in the first go around is the rs6000 and spu both have handlers that get called from the function resolve_overloaded_builtin that takes two argument lists that it needs to validate which overloaded function to use. It isn't a major issue, but it is something that presumably the front ends also do. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
