similar to: [LLVMdev] RFC: Dropping support for building sanitizers with autotools

Unfortunately, we do rely on the Autotools to build for darwin. The lack of proper testing is very unfortunate. In the future, we will either drop the dependency on Makefile/autoconf build or add the support for sanitizer testing. Anna. > On Feb 17, 2015, at 10:54 AM, Kostya Serebryany <kcc at google.com> wrote: > > +1 (in case you still need mine) > > On Thu, Feb 12,

> On Feb 17, 2015, at 4:00 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > > > On Tue, Feb 17, 2015 at 3:37 PM, Anna Zaks <ganna at apple.com <mailto:ganna at apple.com>> wrote: > Unfortunately, we do rely on the Autotools to build for darwin. > > The lack of proper testing is very unfortunate. In the future, we will either drop the dependency on

On 18/02/2015 23:29, Alexey Samsonov wrote: > > On Tue, Feb 17, 2015 at 6:23 PM, Anna Zaks <ganna at apple.com <mailto:ganna at apple.com>> wrote: > > >> On Feb 17, 2015, at 4:00 PM, Alexey Samsonov <vonosmas at gmail.com <mailto:vonosmas at gmail.com>> wrote: >> >> >> On Tue, Feb 17, 2015 at 3:37 PM, Anna Zaks <ganna at

On Mon, Dec 8, 2014 at 2:00 AM, Alexander Potapenko <glider at google.com> wrote: > Hope you're assuming there's always a single copy of common_flags in > the process. > This isn't the case for e.g. ASan+UBSan on Mac, but that's a broken setup. > > What if we let the tools protect specific flags (by adding a bool to > each flag) once they set their values

Hi all, TL;DR 1) We should change the way we parse common runtime flags in sanitizers. 2) We should make ASan aware of the tools it can be combined with (LSan and UBSan). 3) We may have to restrict the tools UBSan can be combined with (currently to ASan) (see [1]) Currently we have two kinds of sanitizer runtime flags: tool-specific flags and "common flags", defined in sanitizer_common

Sorry for the late response. You should check out CMAKE_TOOLCHAIN_FILE logic for Android platform - IIRC build rules for Android are much simpler than for Darwin/Linux, and assume that build tree will be properly configured to build a single compiler-rt runtime for a specific triple. Probably this is the approach you want to eventually use for another platforms. Also check out

The documentation for the sanitizer special case list format[0] says, > The meanining of * in regular expression for entity names is different - it is treated as in shell wildcarding. In SpecialCaseList::parse, we see that this is just replacing * with .*: // Replace * with .* for (size_t pos = 0; (pos = Regexp.find("*", pos)) != std::string::npos; pos +=

+llvm-commits (correct list) On Tue, Sep 22, 2015 at 12:32 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Could you describe the build failures you see after applying this patch? > I'll let Chris judge if adding -Wl,-syslibroot makes sense for iossim, or > that problem should be solved differently. > > On Tue, Sep 22, 2015 at 9:37 AM, Alex Wang via llvm-dev <

Hey Alexey, This bot has been failing for a week, by the looks of it - what's the deal? On Thu, May 7, 2015 at 7:31 PM, <llvm.buildmaster at lab.llvm.org> wrote: > The Buildbot has detected a new failure on builder sanitizer-x86_64-linux > while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17810 >

(+correct cfe-dev list) On Tue, Jan 12, 2016 at 2:57 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi Yuri, > > On Mon, Jan 11, 2016 at 9:53 AM, Yury Gribov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> UndefinedBehaviorSanitizer currently does not check for undefined >> behaviors which result from improper usage

I'm sure it's obvious and I'm just blind, but I can't find the relevant part of that build that's showing a crash. Can you help me out? On Fri, May 8, 2015 at 1:49 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > +Sergey > > The bot failed on (and looks like it still fails even after LLVM r236877) > on AddressSanitizer-i386-linux ::

On 01/13/2016 03:10 AM, Kostya Serebryany wrote: > FTR, here is one way to implement this in the library: > https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h > Search for "check sort predicate for strict weak ordering" Nice, although this wouldn't catch violations of transitivity (which is probably the most important type of bug).

On 01/13/2016 09:57 AM, Kostya Serebryany wrote: > On Tue, Jan 12, 2016 at 10:28 PM, Yury Gribov <y.gribov at samsung.com> wrote: > >> On 01/13/2016 03:10 AM, Kostya Serebryany wrote: >> >>> FTR, here is one way to implement this in the library: >>> >>> https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h

On Thu, Apr 3, 2014 at 9:23 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > I don't think it's a good idea to let user hijack > > the driver and stuff in custom version of > > ASan runtime instead the one installed/built > > with compiler :) > > I'm okay with it. This is open source. If someone wants to put the > sanitizers on a shorter

Inviting Paul to the party (he wrote the libstdc++ sort checker <https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h> ). On Tue, Jan 12, 2016 at 11:09 PM, Yury Gribov <y.gribov at samsung.com> wrote: > On 01/13/2016 10:08 AM, Yury Gribov wrote: > >> On 01/13/2016 09:57 AM, Kostya Serebryany wrote: >> >>> On Tue, Jan 12,

On 28 May 2014 17:44, Justin Bogner <mail at justinbogner.com> wrote: > In the autoconf system, I'm pretty sure compiler-rt's build is triggered > by a Makefile in clang, tools/clang/runtime/compiler-rt/Makefile. This > Makefile comments "We currently only try to generate runtime libraries > on x86", so I guess that's the place to start if you want to get it

Alexey, >> Some good news, the drivers (both gcc and clang) allow us to put the >> '-L' parameters after the '-l' parameters. I made these changes locally and it went really well. The patch to clang is quite small and only one unit-test needed updating. In compiler-rt, I updated the flags passed to clang to include a '-L${COMPILER_RT_BINARY_DIR}/lib' and

On Thu, Apr 3, 2014 at 5:04 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > we would still want to use compiler-rt test-suite in a standalone mode, > to test fully built/installed toolchains, > and even GCC. > > Sounds good. > > > > Clang driver links the static xsan runtimes from a hardcoded > > paths in Clang resource directory, and doesn't

Note that I've set the SA_NODEFER flag for the SEGV handler in the ASan runtime only a couple of days ago. Not sure that could've affected this test though; without that flag the second SEGV would've simply crashed the program. But you can try removing the flag from compiler-rt/trunk/lib/sanitizer_common/sanitizer_posix_libcdep.cc and see if that makes any difference. HTH, Alex On

On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com > wrote: > On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at gmail.com> > wrote: > > Hi, > > > > I consider reducing the usage of blacklist in sanitizer instrumentation > > passes and doing the necessary work in frontend (Clang) instead. > > > > Some