Re: [Boost-users] Valgrind false positive in make_shared -- possible solution

Subject: Re: [Boost-users] Valgrind false positive in make_shared -- possible solution
From: Dave Steffen (dave.steffen_at_[hidden])
Date: 2010-12-01 11:20:52

On Tuesday, November 30, 2010 03:41:29 pm Dave Steffen wrote:
> On Tuesday, November 30, 2010 01:46:39 pm Dave Steffen wrote:
> > On Tuesday, November 30, 2010 03:40:14 am Peter Dimov wrote:
> > > Dave Steffen wrote:
> > > >  Hi
> > > >  
> > > >   Coming back to this issue after a week or two...  trying the above
> > > 
> > > [changing to std::forward]
> > > 
> > > >   made no difference: no compiler warnings, and no change in
> > > >   Valgrind's error messages.
> > > 
> > > Looks like a g++ bug then. You should try reproducing it in a
> > > self-contained example and report it to the GCC Bugzilla. I'm not sure
> > > what we can do on our end to avoid it. (I'll switch to std::forward in
> > > any case, since this seems a good idea in general, but it won't help in
> > > this specific case.)
> > > 
> >   I reported this as GCC bug 46732.  You can see the whole discussion
> >   at
> >   
> >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46732
> >   
> >   but the short version is:
> >     There was a defect in the language, core issue 664
> >     http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#664
> >     
> >     GCC 4.4 predates that issue being resolved, so the only real
> >     workaround
> > 
> > is to
> > 
> >     avoid using -std=c++0x with GCC 4.4
> >  
> >  (thanks to Jonathan Wakely for getting to this so quickly)
> 

  Jonathan Wakely has proposed a fix; since I'm guessing nobody out
  there is watching the bug report, I thought I'd pass this along.

----------------------------------------------------------------------

> GCC 4.4 predates that issue being resolved, so the only real workaround is 
to
> avoid using -std=c++0x with GCC 4.4

Or do something like I did for std::move in my initial implementation of
std::future, which returned scalars by value rather than by rvalue-reference:

  // workaround for CWG issue 664 and c++/34022
  template<typename _Result, bool = is_scalar<_Result>::value>
    struct _Move_future_result
    {
      typedef _Result&& __rval_type;
      static _Result&& _S_move(_Result& __res) { return std::move(__res); }
    };

  // specialization for scalar types returns rvalue not rvalue-reference
  template<typename _Result>
    struct _Move_future_result<_Result, true>
    {
      typedef _Result __rval_type;
      static _Result _S_move(_Result __res) { return __res; }
    };

Boost could use something like this (for GCC 4.4 with -std=c++0x only) to 
avoid
the problem

----------------------------------------------------------------------

  Thanks very much.

-- 
Dave Steffen, Ph.D. - Software Engineer
Numerica Corporation <http://www.numerica.us>
4850 Hahns Peak Drive, Suite 200
Loveland, Colorado 80538
main [phone] x 227   direct [phone]
Email: dave.steffen_at_[hidden]
fax [phone]
This message and any attachments are intended only for the individual
or entity to which the message is addressed.  This is a private
message and may contain privileged information.  If you are neither
the intended recipient nor the agent responsible for delivering the
message to the intended recipient, you are hereby notified that any
review, retransmission, dissemination, or taking of any action in
reliance upon, the information in this communication is strictly
prohibited, and may be unlawful.  If you feel you have received this
communication in error, please notify me immediately by returning this
email to me and deleting it from your computer.