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


On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >
>> > 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.

For functions that are replaceable, what counts is the provenance of the
*definition*, not just of one its declarations.  The sequence of code that you
show is mandated by C++.  Quoting C++11 3.7.4/2

   The library provides default definitions for the global allocation and
   deallocation functions. Some global allocation and deallocation functions
   are replaceable (18.6.1). A C++ program shall provide at most one
   definition of a replaceable allocation or deallocation function. Any such
   function definition replaces the default version provided in the
library (17.6.4.6).
   The following allocation and deallocation functions (18.6) are implicitly
   declared in global scope in each translation unit of a program.

      void* operator new(std::size_t);
      void* operator new[](std::size_t);
      void operator delete(void*);
      void operator delete[](void*);

   These implicit declarations introduce only the function names operator new,
   operator new[], operator delete, and operator delete[].

So, I think we do need to know the definition site of _Znwm.  If it comes from
the implementation, then we are good to go.  Otherwise, we would need
to proceed carefully.

> Aren't user allocator also allowed to make their own exceptions in addition to throw (std::bad_alloc);?

I suspect so, though I don't think the replacement allocation definitions
are allowed to throw arbitrary exceptions.

-- Gaby


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