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: Martin Jambor <mjambor at suse dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: libstdc++ at gcc dot gnu dot org, Paolo Carlini <paolo dot carlini at oracle dot com>, rguenther at suse dot de
- Date: Fri, 17 Apr 2009 18:09:52 +0200
- Subject: Re: Marking C++ allocators as allocators (Was: More function decorations II)
- References: <20090417142039.GC17694@kam.mff.cuni.cz>
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