> >
> > So the existing program needs to overwrite libsup++ symbol like we do with
> > malloc?
> > Of course with user defineed malloc function we should not propagate the
> > attribute,
> > but I think we could have it when we end up calling the runtime.
>
> I suspect the question is whether our current infrastructure permits
> to distinguish
> between declaration of 'operator new' we supply, and 'operator new' defined by
> user. The way we currently arrange for user-defined 'operator new' to take
> over is that it is something that is done at linktime, (so is LTO
> prepared for this?)
I think so (I am not expert though :))
The operator new we supply is called _Znwm and I want the particular decl with
assembler name _Znwm to have malloc attribute. I get it right, it is the
declaration we build by
newtype = cp_build_type_attribute_variant (ptr_ftype_sizetype, newattrs);
newtype = build_exception_variant (newtype, new_eh_spec);
deltype = cp_build_type_attribute_variant (void_ftype_ptr, extvisattr);
deltype = build_exception_variant (deltype, empty_except_spec);
push_cp_library_fn (NEW_EXPR, newtype);
push_cp_library_fn (VEC_NEW_EXPR, newtype);
User's new will be different declarations with different assembler name. It is
up to user to care about malloc attributes or whatever.
Aren't user allocator also allowed to make their own exceptions in addition to
throw (std::bad_alloc);?
Honza
> and ours is searched last.
>
> >
> > Honza
> >>
> >> Alexander
