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

[Evgeniy Stepanov]

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.

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
>