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
