public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "awl03 at doc dot ic dot ac dot uk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
Date: Sun, 10 Jun 2007 19:32:00 -0000	[thread overview]
Message-ID: <20070610193237.22013.qmail@sourceware.org> (raw)
In-Reply-To: <bug-19319-2476@http.gcc.gnu.org/bugzilla/>



------- 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)
{
<bb 0>:
  __comp_ctor  (&<retval>, n);
  return <retval>;
}

Notice that <retval> has its address taken.  Inside the constructor
__comp_ctor() the object is created in the location given by <retval>.
<retval> 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 (&<retval>, &this->_M_impl._M_start);
    return <retval>;
} 

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


  parent reply	other threads:[~2007-06-10 19:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-19319-2476@http.gcc.gnu.org/bugzilla/>
2005-10-23 23:47 ` ppluzhnikov at charter dot net
2005-12-14 17:46 ` ppluzhnikov at charter dot net
2006-03-19  5:11 ` pinskia at gcc dot gnu dot org
2006-11-10  3:09 ` fche at redhat dot com
2006-11-10 16:34 ` p dot van-hoof at qub dot ac dot uk
2006-11-10 16:35 ` p dot van-hoof at qub dot ac dot uk
2006-11-10 23:00 ` ppluzhnikov at charter dot net
2006-11-10 23:31 ` ppluzhnikov at charter dot net
2006-11-14  3:53 ` fche at redhat dot com
2006-11-14  4:26 ` ppluzhnikov at charter dot net
2006-11-14 12:19 ` fche at redhat dot com
2006-11-15  1:22 ` ppluzhnikov at charter dot net
2007-06-10 19:32 ` awl03 at doc dot ic dot ac dot uk [this message]
2007-06-10 19:35 ` awl03 at doc dot ic dot ac dot uk
2007-06-20 19:37 ` fche at redhat dot com
2007-07-12 23:58 ` awl03 at doc dot ic dot ac dot uk
2007-08-27 18:41 ` jason at gcc dot gnu dot org
2008-04-09 19:15 ` fche at redhat dot com
2009-05-07 16:31 ` f dot knauf at mmkf dot de
     [not found] <bug-19319-4@http.gcc.gnu.org/bugzilla/>
2014-02-16  9:59 ` jackie.rosen at hushmail dot com
2005-01-07 22:31 [Bug libmudflap/19319] New: " bredelin at ucla dot edu
2005-01-07 22:42 ` [Bug libmudflap/19319] " fche at redhat dot com
2005-01-07 22:58 ` fche at redhat dot com
2005-01-08 20:03 ` bangerth at dealii dot org
2005-01-10 17:04 ` fche at redhat dot com
2005-01-18  9:35 ` bredelin at ucla dot edu
2005-02-13 18:35 ` cvs-commit at gcc dot gnu dot org
2005-02-13 20:08 ` cvs-commit at gcc dot gnu dot org
2005-02-13 20:09 ` fche at redhat dot com
2005-02-17 15:12 ` cvs-commit at gcc dot gnu dot org
2005-02-19 22:10 ` pinskia at gcc dot gnu dot org
2005-02-19 22:36 ` pinskia at gcc dot gnu dot org
2005-02-19 22:37 ` pinskia at gcc dot gnu dot org
2005-03-10 21:57 ` fche at redhat dot com
2005-04-20  2:36 ` pinskia at gcc dot gnu dot org
2005-08-18 20:05 ` gideon dot amos at canfieldsci dot com
2005-08-18 20:10 ` fche at redhat dot com
2005-08-18 22:36 ` pinskia at gcc dot gnu dot org
2005-09-23 21:35 ` fche at redhat dot com
2005-09-23 21:35 ` cvs-commit at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070610193237.22013.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).