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

Evgeniy Stepanov eugenis at google.com
Tue Aug 26 13:01:15 PDT 2014


These messages are probably about building instrumented libc++ for
asan/tsan/msan testing from compiler-rt build system.

On Tue, Aug 26, 2014 at 10:27 PM, Eric Fiselier <eric at efcs.ca> wrote:
> I added support for "LLVM_USE_SANITIZER" when building and testing last
> week.
>
> I've also noticed that when I use cmake to build libc++ in tree there are
> already some existing messages about
> building different instrumented libc++ versions. I'm not quite sure what
> those are about though. They are not coming from libc++.
>
> /Eric
>
>
> On Tue, Aug 26, 2014 at 10:44 AM, Kostya Serebryany <kcc at google.com> wrote:
>>
>>
>>
>>
>> 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
>>
>>
>




More information about the cfe-commits mailing list