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: Alexander Monakov <amonakov at ispras dot ru>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, "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 19:38:20 +0400 (MSK)
- 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, 22 Aug 2013, Jan Hubicka 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.
Which means you cannot annotate NEW_EXPR with attribute malloc when
-fno-inline is in effect, right? Because then placement new is no longer
optimized out. Testcase, compile with -O2 -fno-inline -fno-ipa-sra:
#include <new>
int foo(void *c)
{
return *(new (c) int);
}