This is the mail archive of the
mailing list for the GCC project.
Re: [C++ patch] Set attributes for C++ runtime library calls
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: 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 10:33:45 -0500
- 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>
On Thu, Aug 22, 2013 at 10:21 AM, Jan Hubicka <email@example.com> wrote:
>> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > > MALLOC attribute. Without it, it is basically impossible to track
>> > > any dynamically allocated objects in the middle-end
>> > operator new is replaceable by user program.
>> But so is malloc? As I understand, the reason why "malloc" attribute is not
>> applicable to operator new is "placement new", which returns aliased memory.
> placement new is optimized to nothing, so it should not affect anything here.
> MALLOC attribute makes the assumtion that you can not get to the return value of
> the function from something that you had previously (i.e. you can not have
> existing pointer to that block of memory). So you can not really implement
> malloc in the same compilation unit you are using it.
Exactly. The same goes for any user allocators -- many of which tend
to be inline,
delegating the hard work to an off-line function.
> 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
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?)
and ours is searched last.