public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/2948
@ 2001-05-30 13:16 Sean McNeil
0 siblings, 0 replies; 2+ messages in thread
From: Sean McNeil @ 2001-05-30 13:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: c++/2948
@ 2001-05-29 10:36 neil
0 siblings, 0 replies; 2+ messages in thread
From: neil @ 2001-05-29 10:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/2948; it has been noted by GNATS.
From: neil@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, sean@mcneil.com
Cc:
Subject: Re: c++/2948
Date: 29 May 2001 17:30:40 -0000
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-05-30 13:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-30 13:16 c++/2948 Sean McNeil
-- strict thread matches above, loose matches on Subject: below --
2001-05-29 10:36 c++/2948 neil
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).