This is the mail archive of the gcc-bugs@gcc.gnu.org mailing 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]

[Bug c++/15967] [3.4/3.5 regression] ICE on ambiguous operator new in class hierarchy


------- 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


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