This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [patch] libbounds an extension of libmudflap with referent object tracking


> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@redhat.com]
> 
> >From a brief reading of the MEng report paper, it seems to me that:
> 
> - the old mudflap bug that breaks c++ has a fix that fell between the
>   cracks: please repost it (cc: me for most reliable attention), and
>   many thanks!

While updating MIRO from GCC 4.1.1 to 4.3, Sebastian and I found that my
'fix' (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319#c27) was actually a
hack that worked around the issue in many cases but caused it to break in
others.  

It appears that GCC 4.1.1 was not correctly setting TREE_ADDRESSIBLE for the
return slot *before* the return-by-value function was called.  The 'fix'
dealt with this by registering the return slot inside this function.
However, in some cases the return slot *was* being correctly registered in
the outer function thus causing it to be registered and  unregistered twice
(whoops).  

It would seem that somewhere between 4.1.1 and 4.3 this was solved elsewhere
in GCC as we were able to remove the hack and both cases now pass.

I notice that you just closed the bug saying "The patch has been committed
for some time, and this test case passes."  Which patch do you mean?  I
looked at the SVN (revision 13385) and it doesn't seem to be my one which is
good.
 
> - to assess the performance effect of the lookup cache by itself,
>   which is missing from the new work, the "lc-*" set of
>   MUDFLAP_OPTIONS could be used to disable it.  Or more accurately, a
>   compiler option could force an out-of-line __mf_check() call for
>   each dereference.

This is useful to know.  The latest MIRO code actually contains caching now,
though it's not as extensive as that in Mudflap.  It has increased
performance considerably but it's still much too slow.  I need to get round
to doing some profiling.

Thanks for your interest.

Alex Lamaison 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]