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]

Re: g++.law/operators24.C and --enable-checking=gcac


On Tue, Jun 06, 2000 at 10:35:07AM -0700, Mark Mitchell wrote:
> 
> The fix is that pushdecl should not be trying to merge things that
> have the same DECL_ASSEMBLER_NAME, but different DECL_NAMEs.  That's
> weird.  The `__builtin_new' that the user declares there should have
> nothing to do with `::operator new'.

That's pretty much what I figured.  I don't know how to do it though...

>  Of course, a user who defines
> __builtin_new may be sadly disappointed when she finds it to be
> replacing `operator new'.  The new ABI will reduce the probability of
> this kind of bug because __builtin_new is spelled _Z<some ugliness>
> that would be a strange name for a function.

Well, __builtin_new is in the implementation's namespace, so we're
allowed to do whatever we like.  It is still surprising, I agree.

> I'll look into fixing this.

Thanks.

You can avoid the crash by adding

      /* If olddecl is an overloaded operator, we must preserve the
         old DECL_NAME.  */
      if (DECL_OVERLOADED_OPERATOR_P (olddecl))
	DECL_NAME (newdecl) = DECL_NAME (olddecl);

to the if block just before

  if (TREE_CODE (newdecl) == NAMESPACE_DECL)
    {
      NAMESPACE_LEVEL (newdecl) = NAMESPACE_LEVEL (olddecl);
    }

in duplicate_decls.  That's not the right fix, of course.

The commentary in duplicate_decls seems to have its terminology
scrambled - it can't decide whether it's clobbering newdecl, olddecl,
or both...

zw

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