<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The sanitizer common and asan that mention 'thread' are failing for me<br>
this morning. How are your bots looking? Last good commit here was<br>
512c616cacf70ca029a2bf719a482b902f3687cd.<br></blockquote><div><br></div><div style>Hm, our bots seem to be green. Could you refer to guilty svn revision?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br>
> You could try preprocessing your report with perl or sed to fix paths<br>
> to your binaries. It would be great to have an option for that in<br>
> asan_symbolize.py.<br>
><br>
> As for addr2line, we just install binutils-multiarch ubuntu package.<br>
<br>
</div>Cool, that gets the job done, thanks. Looks like there's some effort<br>
going into embedding the addr2line functionality into compiler-rt. Is<br>
that something folks are actively working on?<br></blockquote><div><br></div><div style>Well, LLVM has llvm-symbolizer tool, which is analogous to addr2line.</div><div style>For now sanitizer tools are able to use it for out-of-process symbolization</div>
<div style>(e.g. on Linux you won't have to run report through asan_symbolize.py if</div><div style>you provide env variable ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer).</div><div style>We have plans to actually compile the symbolizer into the binary and do</div>
<div style>in-process symbolization, but it's not there yet. Not sure if that's what you mean</div><div style>by "addr2line in compiler-rt".</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> Tests are different: certainly tests that depend on instrumentation<br>
> are built with clang from the same build tree (that is tests "depend" on Clang).<br>
<br>
</div>The compiler-rt library definitions have no dependency on the clang<br>
instrumentation, correct? Only the other way around?<br></blockquote><div><br></div><div style>I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other,</div><div style>so the version of Clang you use should be the same as the version of compiler-rt.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Greg<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, May 30, 2013 at 1:03 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
><br>
> On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>> wrote:<br>
>><br>
>> > Cool, can you use clang 3.3 then? :)<br>
>><br>
>> I can, but digging deeper I see that the compiler-rt sanitizer tests<br>
>> depend on just-built-clang for its object instrumentation. The next time<br>
>> the instrumentation changes, I'd expect those tests to break. If the lit<br>
>> tests that require -fsanitize were moved to the clang repo, then I think<br>
>> it'd be safe to build compiler-rt with clang 3.3 or gcc 4.6.3.<br>
><br>
><br>
> Tests are different: certainly tests that depend on instrumentation are<br>
> built with clang from the same build tree (that is tests "depend" on Clang).<br>
> * when you run "make" in your build tree, you build Clang and runtimes with<br>
> a host compiler<br>
> * when you run "make check-all" in your build tree, you use this Clang and<br>
> runtimes to build/run tests.<br>
><br>
>><br>
>><br>
>><br>
>> Back to Android, I built the ASan shared object and successfully ran this<br>
>> example:<br>
>><br>
>> <a href="https://code.google.com/p/address-sanitizer/source/browse/wiki/example_UseAfterFree.cc?r=1580" target="_blank">https://code.google.com/p/address-sanitizer/source/browse/wiki/example_UseAfterFree.cc?r=1580</a><br>
>><br>
>> But unlike these instructions:<br>
>> <a href="http://www.chromium.org/developers/testing/addresssanitizer" target="_blank">http://www.chromium.org/developers/testing/addresssanitizer</a><br>
>><br>
>> the Android instructions don't mention asan_symbolize.py<br>
>> <a href="https://code.google.com/p/address-sanitizer/wiki/Android" target="_blank">https://code.google.com/p/address-sanitizer/wiki/Android</a><br>
>><br>
>> When I use asan_symbolize.py (from Linux), I see no symbols in the stack<br>
>> trace and the following error messages:<br>
>><br>
>> addr2line: '/data/example_UseAfterFree': No such file<br>
>> addr2line: '/data/<a href="http://libclang_rt.asan-arm-android.so" target="_blank">libclang_rt.asan-arm-android.so</a>': No such file<br>
>> addr2line: '/system/lib/libstdc++.so': No such file<br>
>><br>
>> How can I decode those addresses in the stack trace? Is there a way to<br>
>> configure asan_symbolize.py to find my binaries and<br>
>> arm-linux-androideabi-addr2line?<br>
>><br>
>> Thanks,<br>
>> Greg<br>
>><br>
>> P.S. Thanks for the colorful output. You make address sanitizing feel<br>
>> like Christmas.<br>
>><br>
>><br>
>> On Wed, May 29, 2013 at 7:28 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> For me, UBsan fails with clang 3.2 and passes with clang 3.3.<br>
>>><br>
>>><br>
>>> Cool, can you use clang 3.3 then? :) I think that the reason selected<br>
>>> UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard<br>
>>> may correct me if I'm wrong).<br>
>>> I don't really want to mark these tests as "failing on a certain version<br>
>>> of host compiler".<br>
>>>><br>
>>>><br>
>>>> Using a fixed version allows you to build all clang/llvm/compiler-rt<br>
>>>> with one compiler. It simplifies the build process quite a bit. Also<br>
>>>> better for isolating regressions in compiler-rt, especially if you use<br>
>>>> git-bisect.<br>
>>><br>
>>><br>
>>> I think you may fix a host compiler (it may be clang 3.3 or gcc 4.6.3),<br>
>>> build w/o -Werror and stay happy most of the time.<br>
>>> Bootstrap process (use system compiler to build Clang, use this Clang to<br>
>>> build LLVM+Clang+compiler-rt) isn't really scary, it adds just a few lines<br>
>>> to your build script.<br>
>>> AFAIK some developers actually do this every day. But, yes, this is not<br>
>>> user-friendly, and we probably should document it better (or even provide<br>
>>> the scripts) somewhere...<br>
>>><br>
>>>><br>
>>>><br>
>>>> Greg<br>
>>>><br>
>>>><br>
>>>> On May 29, 2013, at 12:30 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>> UBsan tests work for me when I run "check-ubsan" in both build trees<br>
>>>> (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang).<br>
>>>> It's pretty convenient for us to use fresh Clang to configure LLVM and<br>
>>>> compiler-rt. One major reason is that autoconf/make build system always<br>
>>>> builds compiler-rt with just-built Clang.<br>
>>>> There are other benefits, like keeping sanitizers code "-Werror"-clean<br>
>>>> under the fresh Clang, ability to catch regressions in compiler etc. Why<br>
>>>> would you need a fixed version?<br>
>>>><br>
>>>><br>
>>>> On Tue, May 28, 2013 at 10:26 PM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Okay, dropping gcc 4.4.3 makes sense. How do you feel about using<br>
>>>>> clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It<br>
>>>>> looks like everything works great, but that you just need to make those UB<br>
>>>>> tests 'unsupported' since they fail with "libclang_rt.ubsan was built<br>
>>>>> without __int128 support".<br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Greg<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov<br>
>>>>>> <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>>>>>> wrote:<br>
>>>>>>> > When I build compiler-rt with clang 3.2, all lsan tests pass. The<br>
>>>>>>> > only<br>
>>>>>>> > failing tests I see are in ubsan:<br>
>>>>>>> ><br>
>>>>>>> > Failing Tests (6):<br>
>>>>>>> > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp<br>
>>>>>>> > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp<br>
>>>>>>> > UndefinedBehaviorSanitizer :: Integer/div-zero.cpp<br>
>>>>>>> > UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp<br>
>>>>>>> > UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp<br>
>>>>>>> > UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp<br>
>>>>>>> ><br>
>>>>>>> ><br>
>>>>>>> > When I build with gcc 4.4.3, I need the changes below to get the<br>
>>>>>>> > source to<br>
>>>>>>> > compile (and then the lsan tests fails). What are you all using to<br>
>>>>>>> > build<br>
>>>>>>> > compiler-rt? are you developing on linux, osx or windows? Using<br>
>>>>>>> > gcc or<br>
>>>>>>> > llvm? Which should I expect to work? Any buildbots running?<br>
>>>>>>><br>
>>>>>><br>
>>>>>> As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and<br>
>>>>>> run tests for various sanitizers on our buildbots.<br>
>>>>>> Note that CMake build system of compiler-rt uses host compiler to<br>
>>>>>> build it. On Linux we use:<br>
>>>>>> 1) gcc 4.6.3<br>
>>>>>> 2) tip-of-the-trunk Clang,<br>
>>>>>> and tests pass under both of these.<br>
>>>>>><br>
>>>>>> gcc 4.4.3 seems way too old, so in some sense we've dropped support<br>
>>>>>> for it (you have to make changes, as old gcc is not<br>
>>>>>> smart enough to make some POD variables thread-local).<br>
>>>>>><br>
>>>>>>><br>
>>>>>>> I think we build compiler-rt with the host compiler, except for<br>
>>>>>>> Android. Which is usually a recently-built clang. n Linux, but we<br>
>>>>>>> exercise osx build on our buildbots.<br>
>>>>>>> We never build with compiler-rt not in projects/.<br>
>>>>>>> Our bot scripts are here:<br>
>>>>>>><br>
>>>>>>> <a href="https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave" target="_blank">https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave</a><br>
>>>>>>> The bots itself are not publicly visible, we hope to change that<br>
>>>>>>> soon.<br>
>>>>>>><br>
>>>>>>> ><br>
>>>>>>> > And lastly, are there build instructions to build the Android<br>
>>>>>>> > shared object?<br>
>>>>>>> > Is there any way to build an android static lib? How about for<br>
>>>>>>> > arm-linux?<br>
>>>>>>><br>
>>>>>>> Android runtime is special, we build it in a separate build tree<br>
>>>>>>> configured with<br>
>>>>>>> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake<br>
>>>>>>> See buildbot_cmake.sh for details.<br>
>>>>>>><br>
>>>>>>> ><br>
>>>>>>> > Thanks,<br>
>>>>>>> > Greg<br>
>>>>>>> ><br>
>>>>>>> ><br>
>>>>>>> > diff --git a/lib/interception/interception.h<br>
>>>>>>> > b/lib/interception/interception.h<br>
>>>>>>> > index d50af35..1771d4e 100644<br>
>>>>>>> > --- a/lib/interception/interception.h<br>
>>>>>>> > +++ b/lib/interception/interception.h<br>
>>>>>>> > @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T;<br>
>>>>>>> > typedef __sanitizer::sptr SSIZE_T;<br>
>>>>>>> > typedef __sanitizer::sptr PTRDIFF_T;<br>
>>>>>>> > typedef __sanitizer::s64 INTMAX_T;<br>
>>>>>>> > -typedef __sanitizer::OFF_T OFF_T;<br>
>>>>>>> > -typedef __sanitizer::OFF64_T OFF64_T;<br>
>>>>>>> > +//typedef __sanitizer::OFF_T OFF_T;<br>
>>>>>>> > +//typedef __sanitizer::OFF64_T OFF64_T;<br>
>>>>>>> ><br>
>>>>>>> > // How to add an interceptor:<br>
>>>>>>> > // Suppose you need to wrap/replace system function (generally,<br>
>>>>>>> > from libc):<br>
>>>>>>> > diff --git a/lib/lsan/lsan_allocator.cc<br>
>>>>>>> > b/lib/lsan/lsan_allocator.cc<br>
>>>>>>> > index 9bf27b1..190dce8 100644<br>
>>>>>>> > --- a/lib/lsan/lsan_allocator.cc<br>
>>>>>>> > +++ b/lib/lsan/lsan_allocator.cc<br>
>>>>>>> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator,<br>
>>>>>>> > AllocatorCache,<br>
>>>>>>> > SecondaryAllocator> Allocator;<br>
>>>>>>> ><br>
>>>>>>> > static Allocator allocator;<br>
>>>>>>> > -static THREADLOCAL AllocatorCache cache;<br>
>>>>>>> > +static /*THREADLOCAL*/ AllocatorCache cache;<br>
>>>>>>> ><br>
>>>>>>> > void InitializeAllocator() {<br>
>>>>>>> > allocator.Init();<br>
>>>>>>> > diff --git a/lib/msan/msan_allocator.cc<br>
>>>>>>> > b/lib/msan/msan_allocator.cc<br>
>>>>>>> > index 7435843..3e6adb6 100644<br>
>>>>>>> > --- a/lib/msan/msan_allocator.cc<br>
>>>>>>> > +++ b/lib/msan/msan_allocator.cc<br>
>>>>>>> > @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator;<br>
>>>>>>> > typedef CombinedAllocator<PrimaryAllocator, AllocatorCache,<br>
>>>>>>> > SecondaryAllocator> Allocator;<br>
>>>>>>> ><br>
>>>>>>> > -static THREADLOCAL AllocatorCache cache;<br>
>>>>>>> > +static /*THREADLOCAL*/ AllocatorCache cache;<br>
>>>>>>> > static Allocator allocator;<br>
>>>>>>> ><br>
>>>>>>> > static int inited = 0;<br>
>>>>>>> ><br>
>>>>>>> ><br>
>>>>>>> ><br>
>>>>>>> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev<br>
>>>>>>> > <<a href="mailto:earthdok@google.com">earthdok@google.com</a>> wrote:<br>
>>>>>>> >><br>
>>>>>>> >> I blame this line in lsan/lit_tests/lit.cfg:<br>
>>>>>>> >><br>
>>>>>>> >> # Setup attributes common for all compiler-rt projects.<br>
>>>>>>> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects",<br>
>>>>>>> >> "compiler-rt",<br>
>>>>>>> >> "lib", "lit.common.cfg")<br>
>>>>>>> >><br>
>>>>>>> >><br>
>>>>>>> >> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov<br>
>>>>>>> >> <<a href="mailto:samsonov@google.com">samsonov@google.com</a>><br>
>>>>>>> >> wrote:<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald<br>
>>>>>>> >>> <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>>>>>> >>> wrote:<br>
>>>>>>> >>>><br>
>>>>>>> >>>> > it assumes that compiler-rt is checked out to<br>
>>>>>>> >>>> > llvm/projects/compiler-rt. Apparently, this is a problem.<br>
>>>>>>> >>>><br>
>>>>>>> >>>> I have a patch for this ready. I'll send it to you and<br>
>>>>>>> >>>> llvm-commits.<br>
>>>>>>> >>>> Most of the tests pass with "make check-all" but the<br>
>>>>>>> >>>> recently-added lsan<br>
>>>>>>> >>>> tests are all failing. Do those fail for you as well? If so,<br>
>>>>>>> >>>> can we XFAIL<br>
>>>>>>> >>>> them for now and try to keep the "make check-all" build clean?<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> Thanks! I'll take a look at the patch today. LSan tests work fine<br>
>>>>>>> >>> for me,<br>
>>>>>>> >>> and we have them on our buildbot as well. What are the failures<br>
>>>>>>> >>> you see?<br>
>>>>>>> >>><br>
>>>>>>> >>>><br>
>>>>>>> >>>><br>
>>>>>>> >>>> Thanks,<br>
>>>>>>> >>>> Greg<br>
>>>>>>> >>>><br>
>>>>>>> >>>><br>
>>>>>>> >>>><br>
>>>>>>> >>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov<br>
>>>>>>> >>>> <<a href="mailto:samsonov@google.com">samsonov@google.com</a>><br>
>>>>>>> >>>> wrote:<br>
>>>>>>> >>>>><br>
>>>>>>> >>>>> Hi!<br>
>>>>>>> >>>>><br>
>>>>>>> >>>>> The docs look strange to me - I don't indeed see any CMake<br>
>>>>>>> >>>>> support for<br>
>>>>>>> >>>>> running compiler-rt tests.<br>
>>>>>>> >>>>> Probably compiler-rt folks can comment on this...<br>
>>>>>>> >>>>> I think you should run compilert-rt tests manually by smth.<br>
>>>>>>> >>>>> like<br>
>>>>>>> >>>>> compiler-rt/test/Unit/test.<br>
>>>>>>> >>>>><br>
>>>>>>> >>>>> CMake build system is able of running a bunch of sanitizer<br>
>>>>>>> >>>>> tests<br>
>>>>>>> >>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that<br>
>>>>>>> >>>>> compiler-rt is checked out to llvm/projects/compiler-rt.<br>
>>>>>>> >>>>> Apparently,<br>
>>>>>>> >>>>> this is a problem. There was a patch that tried to address<br>
>>>>>>> >>>>> this, but<br>
>>>>>>> >>>>> it never got committed.<br>
>>>>>>> >>>>><br>
>>>>>>> >>>>><br>
>>>>>>> >>>>><br>
>>>>>>> >>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald<br>
>>>>>>> >>>>> <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>>>>>> >>>>> wrote:<br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>> Anybody working on porting the compiler-rt tests to cmake?<br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>> The online documentation shows a preference for cmake and<br>
>>>>>>> >>>>>> ctest, but<br>
>>>>>>> >>>>>> the CMakeLists file has the comment "Currently the tests have<br>
>>>>>>> >>>>>> not been<br>
>>>>>>> >>>>>> ported to CMake, so disable this directory." How should we be<br>
>>>>>>> >>>>>> running the<br>
>>>>>>> >>>>>> test suite?<br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>> <a href="http://compiler-rt.llvm.org/" target="_blank">http://compiler-rt.llvm.org/</a><br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>> My immediate issue is that "make check-all" fails in the cmake<br>
>>>>>>> >>>>>> build<br>
>>>>>>> >>>>>> when compiler-rt is outside the projects directory. When I<br>
>>>>>>> >>>>>> point to<br>
>>>>>>> >>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit<br>
>>>>>>> >>>>>> still looks for<br>
>>>>>>> >>>>>> lit.common.cfg within "projects/compiler-rt" instead of the<br>
>>>>>>> >>>>>> external<br>
>>>>>>> >>>>>> directory. I use similar CMake variables for Clang and Polly<br>
>>>>>>> >>>>>> and have had<br>
>>>>>>> >>>>>> no trouble. Any recommendations for how to fix?<br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>> Thanks,<br>
>>>>>>> >>>>>> Greg<br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>>> _______________________________________________<br>
>>>>>>> >>>>>> LLVM Developers mailing list<br>
>>>>>>> >>>>>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>>>>> >>>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>>>>> >>>>>><br>
>>>>>>> >>>>><br>
>>>>>>> >>>>><br>
>>>>>>> >>>>><br>
>>>>>>> >>>>> --<br>
>>>>>>> >>>>> Alexey Samsonov, MSK<br>
>>>>>>> >>>><br>
>>>>>>> >>>><br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> --<br>
>>>>>>> >>> Alexey Samsonov, MSK<br>
>>>>>>> >><br>
>>>>>>> >><br>
>>>>>>> ><br>
>>>>>>> ><br>
>>>>>>> > _______________________________________________<br>
>>>>>>> > LLVM Developers mailing list<br>
>>>>>>> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>>>>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>>>>> ><br>
>>>>>>> _______________________________________________<br>
>>>>>>> LLVM Developers mailing list<br>
>>>>>>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Alexey Samsonov, MSK<br>
>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Alexey Samsonov, MSK<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Alexey Samsonov, MSK<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Alexey Samsonov, MSK<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>