This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ patch] Set attributes for C++ runtime library calls


> >
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]