This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Marking C++ allocators as allocators (Was: More function decorations II)


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

Additionally, I have received the email below from Dirk Mueller.  If I
remember  everything correctly,  C++ FE  must be  altered  somehow (in
addition to putting the attributes  into libstdc++) and that scared me
off at that time.  But it may not be that complex, just someone has to
try :-)

IIRC, 

Martin




---------- Forwarded message ----------  
From: Dirk Mueller
Date: 2007/9/12
Subject: Re: Marking C++ operator new as malloc
To: Martin Jambor


On Monday, 10. September 2007, you wrote:

> , I am interested in
> marking (at  least the  default) C++ new  operator as  malloc.

Great.

> Richard
> Guenther has told me you have  done some work in this area already and
> might even have patches to do so.

Yes, I`ve made a couple of one liners to set the MALLOC_LIKE attributes, the
aliasing information. the problem was that I was not able to test the thing
properly, so I did not submit the patches.

> Therefore,  I would  like to  ask you  if you  cold email  me whatever
> information on this topic you feel important, what you think about the
> whole issue and whatever code you migh have and want to share.

I think I started with this:

--- cp/init.c   (revision 125076)
+++ cp/init.c   (working copy)
@@ -1787,6 +1787,8 @@ build_new_1 (tree placement, tree type,
  if (alloc_call == error_mark_node)
    return error_mark_node;

+  DECL_IS_MALLOC (alloc_call) = 1;
+
  gcc_assert (alloc_fn != NULL_TREE);

  /* In the simple case, we can stop now.  */

and tried to refactor/investigate the same for placement new, but never got
around finishing it.

Greetings,
Dirk


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