This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, Benjamin Kosnik <bkoz at redhat dot com>, "pcarlini at unitus dot it" <pcarlini at unitus dot it>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc at gcc dot gnu dot org
- Date: 04 Dec 2002 20:47:19 +0100
- Subject: Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
- Organization: Integrable Solutions
- References: <200212041946.OAA22968@makai.watson.ibm.com>
David Edelsohn <dje@watson.ibm.com> writes:
| >>>>> Diego Novillo writes:
|
| Diego> I see two possible scenarios regarding optimization:
|
| Diego> (a) We merge the infrastructure with the optimizers disabled and
| Diego> keep working on them in mainline. This has the advantage of
| Diego> exposing the code for more testing, but it might disrupt
| Diego> development.
|
| Diego> (b) We don't merge anything for 3.4, keep working on the branch
| Diego> and merge everything for 3.5 or whenever we close the
| Diego> performance gap.
|
| Diego> Sometimes I'm more inclined towards (b), it seems safer.
|
| I would prefer (a) because that allows Tree-SSA to be a GCC
Since (a) depends on acceptance of GIMPLE and GENERIC, which are
invasive and quite not yet mature, I would prefer (b) given the
other invasive works already scheduled for 3.4.
-- Gaby