This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ patch] Set attributes for C++ runtime library calls
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Alexander Monakov <amonakov at ispras dot ru>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Thu, 22 Aug 2013 18:16:44 +0200
- Subject: Re: [C++ patch] Set attributes for C++ runtime library calls
- References: <20130822131927 dot GA18084 at kam dot mff dot cuni dot cz> <CAAiZkiDRZj-Fzy2+zUo9Z2B5ShvJ6K_duNyX1SKfrEZeX1NNZQ at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1308221836460 dot 30125 at monopod dot intra dot ispras dot ru> <20130822152111 dot GB19256 at kam dot mff dot cuni dot cz> <CAAiZkiA5wyTn0A_eMZ8d-crnq0KY0ut6R1ffh+2xsTp51dkWEg at mail dot gmail dot com> <20130822153958 dot GE19256 at kam dot mff dot cuni dot cz> <CAAiZkiCWf43bVyuVJC+D1=ghSLGTXsi5FbWVdUwX1kq4cNvavg at mail dot gmail dot com>
> 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.
This is quite unfortunate. Thre is nothing standard promise about return
value if this default new? I.e. can I have something like
int a;
test()
{
int *b=new (int);
}
with custom implementation of new that returns &a?
While compiling given object file we do not know if the user program happens to
define it somewhere else or not. Even with LTO I do not think we have
mechanism to recognize statically or dynamically linked libsupc++ (we would
have to LTO _Zwnm that will need to stabilize LTO format to start with).
We probably can go with -fno-user-overwritten-new or something similar?
Honza