From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1711 invoked by alias); 12 Mar 2007 01:04:30 -0000 Received: (qmail 1662 invoked by uid 48); 12 Mar 2007 01:04:21 -0000 Date: Mon, 12 Mar 2007 01:04:00 -0000 Message-ID: <20070312010421.1661.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug objc++/31134] [4.3 Regression] Objective-C++ has ran into the tree number limit In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pcarlini at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg01015.txt.bz2 ------- Comment #6 from pcarlini at suse dot de 2007-03-12 01:04 ------- > It's not fair to trade one feature for another (variadic templates > for obj-c++). I agree. > There's been no discussion on the impact of fixing the tree code limit. > I note that a 15% compile time memory usage regression, > , > would be considered a release blocker. By the way, that issue has been already analyzed and seems solvable rather easily, Doug is working on it with Richard' help. > The patch was obviously not fully tested, or the problem was overlooked. > As a backend maintainer, I've seen build and check times grow substantially > with every new release. So, I'm highly suspicious of the process used > to introduce major new features. The tree code limit should have been > fixed first. Yes, you have a point. But now, since because of our "lazyness" we never managed to attack the tree code limit, let's take this "crisis" as an occasion to do that, or at least let's try to our best, instead of reverting completely Doug' work, which is incredibly important for our implementation of C++0x features and, I would say, gives GCC a great competitive advantage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134