Sandra Loosemore - Re: CALL_EXPR representation changes coming; need patch reviewer(s) (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing 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]

Mike Stump wrote:

On Feb 8, 2007, at 3:27 PM, Sandra Loosemore wrote:

Once the patch is approved, we will probably need to ask for a check-in window for the final merge and commit, as described inhttp://gcc.gnu.org/ml/gcc/2006-09/msg00454.html

Hum, what rule for mainline were you thinking of? A no branch merging and no changes to any CALL_EXPR code seem reasonable. I'd hope that you'd not need a complete lock down on any changes rule. If you're thinking about a general no changes lock down, I'd counter propose that you just, up-port to mainline, get that reviewed and approved, svn up the tree, resolve conflicts, build, svn ci, svn up and then do one last build. The cost to others is then just about 0, unless there was some lagging integration work caused by work checked in before your second to last build and the last build.

That is about what I was thinking. The problem is if there are more conflicts introduced during the "build" period between "resolve conflicts" and "svn ci" -- especially if we add "test" after "build". :-) If you're willing to accept that there may be a time period when I'm still cleaning up merge-related problems in checked-in code, that's fine, we can do without the check-in window. OTOH, it'll certainly help reach convergence faster if other people can hold off on checking in CALL_EXPR-related changes while we're trying to get this nailed down.-Sandra

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