Re: More function decorations II (pool_allocator, mt_allocator, debug, stl_list)

[Richard Guenther <rguenther at suse dot de>]

On Mon, 20 Apr 2009, Gabriel Dos Reis wrote:

> On Mon, Apr 20, 2009 at 1:58 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
> > Gaby, I wish you wouldn't set the Reply-To: header; I don't believe
> > you intended that all replies to your messages be taken offlist.
> 
> You are absolutely right; but then that was done behind my back :-(
> Anybody who knows how to convince gmail not to do that for me
> for free, please tell me the magic incantation...
> 
> >
> > On Mon, Apr 20, 2009 at 3:31 AM, Richard Guenther <rguenther@suse.de> wrote:
> >> > In my opinion adding attribute malloc to C++ new (_not_ the placement
> >> > new variants!) does not add any potential sources for miscompiles.
> >
> > On Mon, Apr 20, 2009 at 11:49:11AM -0700, Gabriel Dos Reis wrote:
> >> Even when the operator new implementation just returns a pointer
> >> into a storage buffer statically allocated (therefore another object)
> >> in the problem?  Is this something documented for the attribute?
> >
> > It seems that the malloc attribute requires that there be a barrier
> > to the analysis somewhere.
> 
> I agree.

With our current C-like memory model yes.  And no, we don't have that
and it's a problem that isn't worsened by attribute malloc (the allocator
function itself is an analysis barrier, or more precise, a barrier for
loads and stores - if it gets inlined then we do not see any malloc
attribute anymore and analysis and (mis-)optimization continues like
if we didn't annotate the allocator with attribute malloc).

> > To a user of malloc, pointers returned by separate malloc calls never
> > alias.  But to an implementer of a memory allocator, of course there
> > is aliasing, because the data structures that represent the memory pool
> > are visible, most obviously for a simple allocator that just parcels
> > out chunks of a large array.
> >
> > A user could overload operator new with an allocator that does something
> > weird (maybe reuse storage for equal objects), but that user wouldn't
> > be putting the malloc attribute on her "new" function.
> >
> > It would appear that to prevent trouble, if a function with the malloc
> > attribute is inlined the malloc attribute has to go away (as the
> > implementation details could now be exposed).

It effectively goes away as it is only an annotation for the function
call semantics and we have no way to annotate an inlined body somehow.

> The thing that gets me a bit worried is that the standard allocation
> function 'operator new' is *replaceable* -- not overloadable.  That means
> that user definition gets to replace libstdc++ definition.  Now, what
> do we annotate?  The declaration in the header, or the definition
> hidden somewhere in a .cc file?  I suspect the latter is not useful since
> the compiler would not see it.  However, the former makes me a bit
> nervous, because now we would be adding an annotation that the
> user does not know of (and should not care about) that is not described
> by the C++ standards.

We annotate the declaration in the header.  Because we reasoned that
any conforming implementation of operator new has semantics that makes
that annotation valid (if the operator is not inlined, but then the
annotation goes away anyway).

Richard.