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, 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);
> }

Yes, this is user provided new oprator, not libsupc++ one. We can't automatically make
it MALLOC.

As for LTO question mentioned by Gaby, we currently have notion of runtime
library (i.e.  everything that compiler can autogenerate calls to - libgcc,
libgcov, glibc, ...) and we do not support LTOing those into user programs.  I
think libsupc++ counts in the list.

Getting runtime libraries to be reliably ltoable is interesting problem.  We will
need to annotate all functions that can possibly be used by compiler and hold
them until we are sure they are not (i.e. bit what externally_visible+used does
but not quite).

LTOing libsupc++ new (and transtiively malloc) is even trickier, since C standard
does not really permit to change type of a block of memory that happens with
malloc/free pair. It is easy to construct programs breaking aliasing rules
with inlined malloc/free implementation (as is with wrong use of placement news).
If we will ever LTO it, we will need to have some sort of optimization barrier
on those, so malloc implementation code does not mix with other code in a way
we understand.

Honza


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