This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
- From: "hjl at lucon dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Aug 2007 21:57:31 -0000
- Subject: [Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
- References: <bug-33199-682@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #11 from hjl at lucon dot org 2007-08-27 21:57 -------
build_new_1 has
/* Now, check to see if this function is actually a placement
allocation function. This can happen even when PLACEMENT is NULL
because we might have something like:
struct S { void* operator new (size_t, int i = 0); };
A call to `new S' will get this allocation function, even though
there is no explicit placement argument. If there is more than
one argument, or there are variable arguments, then this is a
placement allocation function. */
placement_allocation_fn_p
= (type_num_arguments (TREE_TYPE (alloc_fn)) > 1
|| varargs_function_p (alloc_fn));
/* Preevaluate the placement args so that we don't reevaluate them for a
placement delete. */
if (placement_allocation_fn_p)
{
tree inits;
stabilize_call (alloc_call, &inits);
if (inits)
alloc_expr = build2 (COMPOUND_EXPR, TREE_TYPE (alloc_expr), inits,
alloc_expr);
}
...
/* If any part of the object initialization terminates by throwing an
exception and a suitable deallocation function can be found, the
deallocation function is called to free the memory in which the
object was being constructed, after which the exception continues
to propagate in the context of the new-expression. If no
unambiguous matching deallocation function can be found,
propagating the exception does not cause the object's memory to be
freed. */
if (flag_exceptions && ! use_java_new)
{
enum tree_code dcode = array_p ? VEC_DELETE_EXPR : DELETE_EXPR;
tree cleanup;
/* The Standard is unclear here, but the right thing to do
is to use the same method for finding deallocation
functions that we use for finding allocation functions. */
cleanup = build_op_delete_call (dcode, alloc_node, size,
globally_qualified_p,
(placement_allocation_fn_p
? alloc_call : NULL_TREE),
alloc_fn);
I think it is related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199