similar to: [LLVMdev] UBSan on AArch64

Hi Evgeniy, So, to XFAIL some UBSAN failues, I found an issue: UndefinedBehaviorSanitizer-AddressSanitizer :: TestCases/TypeCheck/vptr.cpp UndefinedBehaviorSanitizer-Standalone :: TestCases/Misc/missing_return.cpp These two tests fail on that configuration, but pass when reversed. So, if I XFAIL: armv7l..., I get the following error: UndefinedBehaviorSanitizer-AddressSanitizer ::

Folks, As of this run: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746 There are three classes of failures that need fixing before we get the bot green: 1. AddressSanitizer.BuiltinLongJmpTest Unit Test Two configurations fail: * Asan-arm-inline-Test * Asan-arm-with-calls-Test I wonder what's the best way to run it individually and reduce the error. I'm not

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

I blame this line in lsan/lit_tests/lit.cfg: # Setup attributes common for all compiler-rt projects. compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", "compiler-rt", "lib", "lit.common.cfg") On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com>wrote: > > On Fri, May 24,

On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > failing tests I see are in ubsan: > > Failing Tests (6): > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp > UndefinedBehaviorSanitizer ::

UBsan tests work for me when I run "check-ubsan" in both build trees (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang). It's pretty convenient for us to use fresh Clang to configure LLVM and compiler-rt. One major reason is that autoconf/make build system always builds compiler-rt with just-built Clang. There are other benefits, like keeping sanitizers code

On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <garious at gmail.com> wrote: > For me, UBsan fails with clang 3.2 and passes with clang 3.3. > Cool, can you use clang 3.3 then? :) I think that the reason selected UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard may correct me if I'm wrong). I don't really want to mark these tests as "failing

I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests are failing: $ make check-ubsan … ******************** Testing Time: 2.36s ******************** Failing Tests (11): UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp

On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> > wrote: > > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > > failing tests I see are in ubsan: > > > > Failing Tests (6): > > UndefinedBehaviorSanitizer ::

When I build compiler-rt with clang 3.2, all lsan tests pass. The only failing tests I see are in ubsan: Failing Tests (6): UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp UndefinedBehaviorSanitizer ::

On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Cool, can you use clang 3.3 then? :) > > I can, but digging deeper I see that the compiler-rt sanitizer tests > depend on just-built-clang for its object instrumentation. The next time > the instrumentation changes, I'd expect those tests to break. If the lit > tests that require

I've been working on adding UBSan support to CMake (so that errors found by it can be uploaded to CDash for viewing). One problem is that the message is very generic. The patch here addes 'UndefinedBehaviorSanitizer' to the message so that they may be detected more easily. If something else is wanted (such as the '===' lines from ASan or TSan to cope with things like printing

Some more information … On Jan 4, 2013, at 6:56 PM, Meador Inge wrote: > I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests > are failing: > > $ make check-ubsan > > … > > ******************** > Testing Time: 2.36s > ******************** > Failing Tests (11): > UndefinedBehaviorSanitizer ::

I also encounter this issue and solved it locally by implementing this 2 functions. - The linux version of StartSymbolizerSubprocess uses only POSIX function and can be reused as is on OS X (maybe we should move it in a new sanitizer_symbolizer_posix.cc file) - I have a simple implementation of GetListOfModules (see the attached file) but it required 10.6 at least. That said, implementing this

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.

Hello, I have several low priority UBSan questions... (1) Is there a way for UBSan to print its output to a file that the user specified (e.g. via option) instead of dumping everything on stderr? (2) Out of curiosity, why is the name of the option for printing the stacktrace spelled "UBSAN_OPTIONS=print_stacktrace=1", though the allowed value is 1? Since the only one value is

The sanitizer common and asan that mention 'thread' are failing for me this morning. How are your bots looking? Last good commit here was 512c616cacf70ca029a2bf719a482b902f3687cd. > You could try preprocessing your report with perl or sed to fix paths > to your binaries. It would be great to have an option for that in > asan_symbolize.py. > > As for addr2line, we just

Hi all, UndefinedBehaviorSanitizer currently does not check for undefined behaviors which result from improper usage of standard library functions. One notorious instance of such errors is invalid usage of qsort or bsearch routines (or std::sort and friends in case of C++): * using comparison function that violates ordering axioms (reflexivity, symmetry, transitivity) * returning unstable