From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6335 invoked by alias); 15 Jun 2004 00:04:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 6303 invoked by alias); 15 Jun 2004 00:04:19 -0000 Date: Tue, 15 Jun 2004 00:04:00 -0000 Message-ID: <20040615000419.6301.qmail@sourceware.org> From: "mark at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040612225420.15967.wwieser@gmx.de> References: <20040612225420.15967.wwieser@gmx.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/15967] [3.4/3.5 regression] ICE on ambiguous operator new in class hierarchy X-Bugzilla-Reason: CC X-SW-Source: 2004-06/txt/msg01796.txt.bz2 List-Id: ------- Additional Comments From mark at codesourcery dot com 2004-06-15 00:04 ------- Subject: Re: [3.4/3.5 regression] ICE on ambiguous operator new in class hierarchy giovannibajo at libero dot it wrote: >>A more limited patch to just check for null and give an error might >>be better for 3.4. > > > And what kind of error message can we emit? "Cannot find operator new" is > wrong, because there are two operator new. "Ambiguous operator new" could be > emitted, but then we have a small regression from 3.3 that used to emit the > list of ambiguous oveloads (with correct line information) That's not a regression worth worrying about. , plus it's totally > against lookup_fnfields/lookup_member API which says that NULL means no symbol > found. And so? :-) Unless you can prove that returning a TREE_LIST will not result in a problem anywhere else -- including other ice-on-invalid cases -- your patch is not a win on the release branch. If we have code that's failing to handle a TREE_LIST as the return value -- and we probably do, since the function is never returning that -- then we risk problems if we do that. For 3.4, please just have the caller say "no suitable 'operator new'" and leave it at that. That's sufficiently ambiguous that it will not be a lie, but still gives the user a good clue. Much better than an ICE. For mainline, your patch is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15967