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

["giovannibajo at libero dot it" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From giovannibajo at libero dot it  2004-06-14 23:51 -------
Subject: Re:  [3.4/3.5 regression] ICE on ambiguous operator new in class hierarchy

jason at gcc dot gnu dot org wrote:

> My inclination would be to put Giovanni's
> patch on the trunk; the caller failing
> to deal with NULL is an implicit assertion that the lookup will never
> be NULL.

It cannot be NULL because at that point we already checked that
TYPE_HAS_ARRAY_NEW_OPERATOR, or TYPE_HAS_NEW_OPERATOR. If the lookup finds no
operator new, there is something very broken somewhere, so an ICE is ok.

Right now, we were getting NULL because lookup_fnfields was returning NULL in
case of ambiguity, which is against its description: when protect=2, if there
is ambiguity, we want an ambiguity.

> That assertion was tripped in this case, so he's fixing the lookup to
> conform to the assertion.

Exactly.

> 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), plus it's totally
against lookup_fnfields/lookup_member API which says that NULL means no symbol
found.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15967