This is the mail archive of the gcc@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: [RFC] Marking C++ new operator as malloc?


"Richard Guenther" <richard.guenther@gmail.com> writes:

> On 9/9/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> >
> > Which brings back the fact that you cannot implement malloc in C
> > (you certainly remember the discussions about C++ placement new
> > handling wrt aliasing).  To re-use the machinery we invented there
> > we would need to place a CHANGE_DYNAMIC_TYPE_EXPR for
> > the pointer assignment resulting from inlining a function with
> > attribute malloc set.  As you say, unless we are inlining such functions
> > we are safe in practice.
> 
> Actually this looks nice in general.  We could implement placement
> new in C this way:
> 
>   extern inline T * __attribute__((malloc)) placement_new (void *p)
>   { return p; }
> 
> if we can somehow encode the target type here.  Note that only
> type-based aliasing is a problem with this discussion - PTA will
> be obviously fine if new is inlined as it will see that both pointers
> are related and we loose the 'malloc' attribution on the target pointer
> during inlining.

CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course.  So perhaps
we need __attribute__ ((change_dynamic_type))?

Or actually of course __attribute__ ((malloc)) is fine but we could
throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a
function.  That ought to do the right thing for C malloc
implementations as well, I think.

Ian


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