[libcxx] r215740 - Revert "Turn off extern templates for most uses."

[Kostya Serebryany]

On Tue, Aug 26, 2014 at 2:31 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com
> wrote:

> As Chandler said, disabling extern templates may help with some simple
> tests, but the only reliable way to get rid of MSan false positives is
> linking with instrumented libc++.
>
> We should concentrate on making is easier to build and use
> instrumented libc++ instead.
>
Yes, please!

>
> On Mon, Aug 18, 2014 at 6:30 AM, Eric Fiselier <eric at efcs.ca> wrote:
> >> FWIW, I don't think that MSan was *ever* intended to not have false
> >> positives with an uninstrumented standard library. So I really don't
> >> understand why this is an interesting thing to dig into.
> >
> > That is new information to me so I'll have to take that into
> consideration.
> > What I was trying to avoid was breaking MSAN usability for end users of
> > libc++.
> > Since its unlikely that they have a instrumented standard library it
> would
> > be nice if their system libc++ didn't always cause the first MSAN
> failure.
> >
> > Since __attribute__((__always_inline__)) seems to cause a lot of these
> > failures I imagine it is possible to reduce the FP's without removing the
> > extern template declarations.
> > In that case it might still be work putting time into.
> >
> > /Eric
> >
> >
> > On Sun, Aug 17, 2014 at 8:24 PM, Howard Hinnant <
> howard.hinnant at gmail.com>
> > wrote:
> >>
> >> On Aug 17, 2014, at 9:26 PM, Justin Bogner <mail at justinbogner.com>
> wrote:
> >>
> >> > Howard Hinnant <howard.hinnant at gmail.com> writes:
> >> >> On Aug 17, 2014, at 9:06 PM, Justin Bogner <mail at justinbogner.com>
> >> >> wrote:
> >> >>
> >> >>> I really don't think it's worth the cost of insantiating these very
> >> >>> fundamental templates in *every single user* to work around a
> >> >>> limitation
> >> >>> in the memory sanitizer. This is an unreasonable amount of overhead
> >> >>> for
> >> >>> standard library types.
> >> >>
> >> >> Always measure.  I’m not saying you’re wrong.  I’m saying you’re
> >> >> stating a performance conclusion without measurements (which should
> >> >> never be acceptable).
> >> >
> >> > I did measure :) Though, I sent it to llvm-dev and it probably
> should've
> >> > been cfe-dev. Sorry about that.
> >> >
> >> > http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075793.html
> >>
> >> Ah, I have not been monitoring llvm-dev.  Thank you for the link.
> >>
> >> Howard
> >>
> >
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140826/354505bf/attachment.html>