From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25282 invoked by alias); 4 Jun 2008 17:35:06 -0000 Received: (qmail 23402 invoked by uid 48); 4 Jun 2008 17:34:21 -0000 Date: Wed, 04 Jun 2008 17:35:00 -0000 Message-ID: <20080604173421.23401.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/23383] builtin array operator new is not marked with malloc attribute In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "davidxl at gcc dot gnu dot org" 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: 2008-06/txt/msg00169.txt.bz2 ------- Comment #15 from davidxl at gcc dot gnu dot org 2008-06-04 17:34 ------- (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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383