From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22046 invoked by alias); 10 Jun 2007 19:32:46 -0000 Received: (qmail 22014 invoked by uid 48); 10 Jun 2007 19:32:37 -0000 Date: Sun, 10 Jun 2007 19:32:00 -0000 Message-ID: <20070610193237.22013.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "awl03 at doc dot ic dot ac dot uk" 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: 2007-06/txt/msg00698.txt.bz2 ------- Comment #27 from awl03 at doc dot ic dot ac dot uk 2007-06-10 19:32 ------- I have been writing my own bounds-checker based on Mudflap. While doing so I had to tackle this same problem. My flatmate and I tracked it down to the fact that, although function parameters and variables are registered if their address is ever taken, the return value is not. This is a problem in return-by-value where the result is returned directly without an intermediate variable. For example: class bob { public: int i; bob(int n) { i = n; } }; bob f(int n) { return bob(n); } int main() { bob b = f(0); } Here bob is constructed directly in the return statement in f(). In GIMPLE this looks like: bob f(int) (n) { : __comp_ctor (&, n); return ; } Notice that has its address taken. Inside the constructor __comp_ctor() the object is created in the location given by . has not been registered by f() as return values are not registered, nor has it been registered by main() (where the object finally ends up) because nothing there uses its address. This happens a lot in the STL, hence why it shows up whenever template, map etc., are used: iterator begin() { return iterator (this->_M_impl._M_start); } which is gimplified to into: iterator begin() { comp_ctor (&, &this->_M_impl._M_start); return ; } If Mudflap is changed to register these return values, the violations go away :) I have created a patch that does this but, as I'm a relative newbie, it could all be complete rubbish in which case I apologise. This deals with the problem for the initial testcase, the simplified test by Frank Ch. Eigler and the test by Paul Pluzhnikov. It does not fix the others as these are caused by a different problem, namely objects created by external library calls are not registered by Mudflap and so it thinks there is a violation if you use one of these foreign pointers. I hope this helps and I would be very glad of feedback. Alex Lamaison -- awl03 at doc dot ic dot ac dot uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |awl03 at doc dot ic dot ac | |dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319