This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Marking C++ allocators as allocators (Was: More function decorations II)
- From: Richard Guenther <rguenther at suse dot de>
- To: Martin Jambor <mjambor at suse dot cz>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, libstdc++ at gcc dot gnu dot org, Paolo Carlini <paolo dot carlini at oracle dot com>
- Date: Fri, 17 Apr 2009 18:46:58 +0200 (CEST)
- Subject: Re: Marking C++ allocators as allocators (Was: More function decorations II)
- References: <20090417142039.GC17694@kam.mff.cuni.cz> <20090417160952.GC4630@virgil.suse.cz>
On Fri, 17 Apr 2009, Martin Jambor wrote:
> Hi,
>
> On Fri, Apr 17, 2009 at 04:20:40PM +0200, Jan Hubicka wrote:
> >
> > I wonder, should not be the allocators somehow marked via malloc
> > attribute? That one provide very important hint for alias analysis and
> > also Martin's IPA stuff.
> >
>
> Yep, I'd appreciate such a thing desperately, yet apparently it is not
> as easy as marking the damned things with a flag :-)
>
> I have learned all I know about this issue either from PR 23383
> (builtin array operator new is not marked with malloc attribute) or
> from the mailing list thread at
> http://gcc.gnu.org/ml/gcc/2007-09/msg00159.html
Fun to re-read this ;) I will try to put together a summary of the
arguments on the wiki.
One of my next immediate projects for GCC 4.5 is to finally put an
end on this dynamic type/lifetime of memory issues (aka placement
new, aka CHANGE_DYNAMIC_TYPE_EXPR, aka we-cannot-implement-malloc-in-C)
by changing GCCs memory model to make a store of type T to memory M
change its dynamic type to T (for type-based alias analysis).
Richard.