From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29562 invoked by alias); 4 Jan 2012 00:29:51 -0000 Received: (qmail 29553 invoked by uid 22791); 4 Jan 2012 00:29:50 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_DX X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 00:29:38 +0000 From: "xinliangli at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/23383] builtin array operator new is not marked with malloc attribute Date: Wed, 04 Jan 2012 00:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: alias, missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: xinliangli at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg00327.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383 --- Comment #16 from davidxl 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