search for: dsl11

.... I've CC'ed the authors of the potentially misleading lines so they can decide what do about the warnings (if anything). I'm wondering if clang-format is making some inappropriate choices here or these are just genuine mistakes. Anyway here are the ones I saw in passing. ``` /home/dsl11/dev/llvm-upstream/src/lib/MC/MCParser/DarwinAsmParser.cpp: In member function ‘bool {anonymous}::DarwinAsmParser::parseVersionMin(llvm::StringRef, llvm::SMLoc)’: /home/dsl11/dev/llvm-upstream/src/lib/MC/MCParser/DarwinAsmParser.cpp:962:3: warning: this ‘if’ clause does not guard... [-Wmisleading-i...

...st.txt`` option as documented at [2]. I'm using Clang 3.7 ( Arch Linux package 3.7.0-6). The sort of reported leaks I see are ``` ==9912==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x4df4a0 in operator new(unsigned long) (/home/dsl11/dev/klee/klee/build_asan/unittests/Expr/Release+Asserts/ExprTests+0x4df4a0) #1 0x4f76e1 in klee::Array::CreateArray(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, klee::ref<klee::ConstantExpr> const*, klee::ref&...

...k-origins" LDFLAGS="-fsanitize=memory" python scripts/mk_make.py --build build_msan_clang --noomp --debug cd build_msan_clang make make c_example LD_LIBRARY_PATH=`pwd` ./c_example ==26936==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7fa7d906f3b0 in Z3_open_log /home/dsl11/dev/klee/z3/z3_upstream/build_msan_clang/../src/api/api_log.cpp:33:13 #1 0x55c0c03107f5 in main /home/dsl11/dev/klee/z3/z3_upstream/build_msan_clang/../examples/c/test_capi.c:2794:5 #2 0x7fa7d78f960f in __libc_start_main (/usr/lib/libc.so.6+0x2060f) #3 0x55c0c024d838 in _start (/home/ds...

Hi, I've taken a look at the binary tarballs for clang+llvm-3.6.2-rc1-* that have been uploaded and observed the following: * All uploaded tarballs include the generated CMake files apart from ``clang+llvm-3.6.2-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz``. These files (share/llvm/cmake/*.cmake) are missing in this tarball. * Inside the Ubuntu tarball the directory is not consistently named

Hi, # TL;DR I've been building an application with and without the address sanitizer (with gcc 5.3 and clang 3.7.1) and I've observed that the application's behaviour changes (assertion hit/ not hit). I'm wondering if this could be a bug in address sanitizer or if the application I'm running is just buggy (e.g. doing bad things like relying on memory layout, etc.). I'm

...he same. Does anyone have any idea why this happening and what I can do to fix it? Thanks, Dan Liew. [1] http://llvm.org/releases/2.9/llvm-gcc-4.2-2.9.source.tgz [2] http://llvm.org/releases/2.9/llvm-2.9.tgz [3] http://klee.llvm.org/ [4] http://pastebin.com/YMRNqXjD [5] http://www.doc.ic.ac.uk/~dsl11/llvm-gcc-compile.log [6] http://www.doc.ic.ac.uk/~dsl11/crtstuff.s [7] http://www.doc.ic.ac.uk/~dsl11/crtstuff.i

Hi, On Sun, Jan 17, 2016 at 1:04 PM, Dan Liew <dan at su-root.co.uk> wrote: > On 16 January 2016 at 20:21, Ismail Donmez <ismail at i10z.com> wrote: >> On Sat, Jan 16, 2016 at 9:33 PM, Dan Liew <dan at su-root.co.uk> wrote: >>>> I am trying to enable this on openSUSE but it seems to break >>>> standalone lldb (note that we don't ship static