This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
- From: "xinliangli at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 04 Jan 2012 00:28:55 +0000
- Subject: [Bug c++/23383] builtin array operator new is not marked with malloc attribute
- Auto-submitted: auto-generated
- References: <bug-23383-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #16 from davidxl <xinliangli at gmail dot com> 2012-01-04 00:28:55 UTC ---
A related topic - aliasing property of realloc -- the malloc attribute is not
applied in the glibc header and the comment is like
/* __attribute_malloc__ is not used, because if realloc returns
the same pointer that was passed to it, aliasing needs to be allowed
between objects pointed by the old and new pointers. *
It is true that the realloc can return an address is physically aliased with
the pointer passed to it -- but assuming no-alias by the compiler should cause
no harm -- as all code motions/CSEs across the realloc call will not be
possible because realloc may modify/use the memory location.
Any comment on this?
David
(In reply to comment #15)
> (In reply to comment #14)
> > We do the exact opposite - type-based rules override points-to must-alias
> > information (or really may-alias information). Also for the proposed scheme
> > to work you need to guarantee that you always can compute correct points-to
> > relations (I mean, if points-to information says pt_anything and if you
> > then assume must-alias and thus a conflict then you simply disable TBAA
> > completely).
> >
>
> Right, in general, type alias rules should override field and flow insensitive
> pointer aliasing information as they really have very low confidence level
> (especially for pt_anything case which is just a baseless guess) -- but
> precise/trustworthy aliasing info should be checked before assertion based
> alias information and decide whether to proceed.
>
> For example:
>
> if (no_alias_according_to_conservative_pointer_info) return no_alias;
> if (no_alias_according_to_precise_pointer_info) return no_alias;
> if (must_alias or definitely_may_alias) return may/must_alias; (1)
>
> // now proceed with type based rules, etc.
>
>
> This is in theory. In practice, it can be tricky to tag the confidence level of
> aliasing info.
>
> David