From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean McNeil To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c++/2948 Date: Wed, 30 May 2001 13:16:00 -0000 Message-id: <20010530201602.17763.qmail@sourceware.cygnus.com> X-SW-Source: 2001-05/msg01048.html List-Id: The following reply was made to PR c++/2948; it has been noted by GNATS. From: Sean McNeil To: neil@gcc.gnu.org Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Subject: Re: c++/2948 Date: Wed, 30 May 2001 13:12:54 -0700 --------------5BDE7A2D0A035EFAA8BCB806 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have found the following information in cp/decl.c: /* In a virtual destructor, we must call delete. */ if (DECL_VIRTUAL_P (current_function_decl)) { tree if_stmt; tree virtual_size = c_sizeof (current_class_type); /* [class.dtor] At the point of definition of a virtual destructor (including an implicit definition), non-placement operator delete shall be looked up in the scope of the destructor's class and if found shall be accessible and unambiguous. */ exprstmt = build_op_delete_call (DELETE_EXPR, current_class_ptr, virtual_size, LOOKUP_NORMAL | LOOKUP_SPECULATIVELY, NULL_TREE); if_stmt = begin_if_stmt (); finish_if_stmt_cond (build (BIT_AND_EXPR, integer_type_node, current_in_charge_parm, integer_one_node), if_stmt); finish_expr_stmt (exprstmt); finish_then_clause (if_stmt); finish_if_stmt (); } which accounts for the undefined reference to the "operator delete (void*)" I am seeing. Now... why would a virtual destructor require a call to the delete operator would be nice to know, yet why this behaves differently under the different scenarios is a bigger puzzle to me. The differences I've seen with the #pragma implementation are documented as relating to templates, not virtual destructors. I have verified the introduction on the undefined reference is from the above code by commenting it out. Sean neil@gcc.gnu.org wrote: > Synopsis: different behaviour directly to C++ vs. saving -E output > > State-Changed-From-To: feedback->analyzed > State-Changed-By: neil > State-Changed-When: Tue May 29 10:30:40 2001 > State-Changed-Why: > Appears to be a C++ front-end bug in interpreting filenames > passed from CPP when handling #pragma implementation. > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2948&database=gcc --------------5BDE7A2D0A035EFAA8BCB806 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have found the following information in cp/decl.c:

  /* In a virtual destructor, we must call delete.  */
  if (DECL_VIRTUAL_P (current_function_decl))
    {
      tree if_stmt;
      tree virtual_size = c_sizeof (current_class_type);

      /* [class.dtor]

  At the point of definition of a virtual destructor (including
  an implicit definition), non-placement operator delete shall
  be looked up in the scope of the destructor's class and if
  found shall be accessible and unambiguous.  */
      exprstmt = build_op_delete_call
 (DELETE_EXPR, current_class_ptr, virtual_size,
  LOOKUP_NORMAL | LOOKUP_SPECULATIVELY, NULL_TREE);

      if_stmt = begin_if_stmt ();
      finish_if_stmt_cond (build (BIT_AND_EXPR, integer_type_node,
      current_in_charge_parm,
      integer_one_node),
      if_stmt);
      finish_expr_stmt (exprstmt);
      finish_then_clause (if_stmt);
      finish_if_stmt ();
    }

which accounts for the undefined reference to the "operator delete (void*)" I am seeing.  Now... why would a virtual destructor require a call to the delete operator would be nice to know, yet why this behaves differently under the different scenarios is a bigger puzzle to me.  The differences I've seen with the #pragma implementation are documented as relating to templates, not virtual destructors.

I have verified the introduction on the undefined reference is from the above code by commenting it out.

Sean

neil@gcc.gnu.org wrote:

Synopsis: different behaviour directly to C++ vs. saving -E output

State-Changed-From-To: feedback->analyzed
State-Changed-By: neil
State-Changed-When: Tue May 29 10:30:40 2001
State-Changed-Why:
    Appears to be a C++ front-end bug in interpreting filenames
    passed from CPP when handling #pragma implementation.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2948&database=gcc

--------------5BDE7A2D0A035EFAA8BCB806--