public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Sean McNeil <sean@mcneil.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/2948
Date: Wed, 30 May 2001 13:16:00 -0000 [thread overview]
Message-ID: <20010530201602.17763.qmail@sourceware.cygnus.com> (raw)
The following reply was made to PR c++/2948; it has been noted by GNATS.
From: Sean McNeil <sean@mcneil.com>
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
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I have found the following information in cp/decl.c:
<p> /* In a virtual destructor, we must call delete. */
<br> if (DECL_VIRTUAL_P (current_function_decl))
<br> {
<br> tree if_stmt;
<br> tree virtual_size = c_sizeof (current_class_type);
<p> /* [class.dtor]
<p> At the point of definition of a virtual destructor (including
<br> an implicit definition), non-placement operator delete shall
<br> be looked up in the scope of the destructor's class and if
<br> found shall be accessible and unambiguous. */
<br> exprstmt = build_op_delete_call
<br> (DELETE_EXPR, current_class_ptr, virtual_size,
<br> LOOKUP_NORMAL | LOOKUP_SPECULATIVELY, NULL_TREE);
<p> if_stmt = begin_if_stmt ();
<br> finish_if_stmt_cond (build (BIT_AND_EXPR,
integer_type_node,
<br> current_in_charge_parm,
<br> integer_one_node),
<br> if_stmt);
<br> finish_expr_stmt (exprstmt);
<br> finish_then_clause (if_stmt);
<br> finish_if_stmt ();
<br> }
<p>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.
<p>I have verified the introduction on the undefined reference is from
the above code by commenting it out.
<p>Sean
<p>neil@gcc.gnu.org wrote:
<blockquote TYPE=CITE>Synopsis: different behaviour directly to C++ vs.
saving -E output
<p>State-Changed-From-To: feedback->analyzed
<br>State-Changed-By: neil
<br>State-Changed-When: Tue May 29 10:30:40 2001
<br>State-Changed-Why:
<br> Appears to be a C++ front-end bug in interpreting
filenames
<br> passed from CPP when handling #pragma implementation.
<p><a href=" http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2948&database=gcc" ;> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2948&database=gcc </a></blockquote>
</html>
--------------5BDE7A2D0A035EFAA8BCB806--
next reply other threads:[~2001-05-30 13:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-30 13:16 Sean McNeil [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-05-29 10:36 c++/2948 neil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010530201602.17763.qmail@sourceware.cygnus.com \
--to=sean@mcneil.com \
--cc=gcc-prs@gcc.gnu.org \
--cc=nobody@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).