similar to: Buildling with/without AddressSanitizer causes divergent execution behaviour

Hi Kostya & Yury, Thanks for the advice. On 9 February 2016 at 22:48, Kostya Serebryany <kcc at google.com> wrote: > Hi Dan, > > On Tue, Feb 9, 2016 at 10:57 AM, Dan Liew <dan at su-root.co.uk> wrote: >> >> Hi, >> >> # TL;DR >> >> I've been building an application with and without the address >> sanitizer (with gcc 5.3 and

On 11 February 2016 at 17:08, Reid Kleckner <rnk at google.com> wrote: > On Thu, Feb 11, 2016 at 5:53 AM, Dan Liew via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> > Can you somehow verify that this heap-use-after-free is happening? >> > E.g. print all the pointer values coming from memory::allocate, coming >> > into >> >

Hi, I'm currently trying to find and fix memory leaks (compiling with ``-fsanitize=address``) in the KLEE tool [1] an having found some leaks and I'm having trouble suppressing them. I'm trying to suppress them using the ``-fsanitize-blacklist=blacklist.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 ```

Hi, I was building LLVM with gcc 6.1.1 recently and it was spitting out some warnings relating to misleading indention that caught my eye. This wasn't a fresh build so I may have missed some. 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

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 Chris, Thanks for answering, Can u clarify on this comment mentioned in https://github.com/Z3Prover/z3/issues/861 . cplusplus no exception support · Issue #861 · Z3Prover/z3 · GitHub - LLVM's *source code* does not use exceptions for performance reasons and so is compiled by default with -fno-exceptions. When using LLVM's libraries via it's C++ interface it is important

LLVM does not allow the use of exceptions in our code. We do not allow throwing or catching them. That does not mean you cannot compile the code with exceptions enabled, it just means we don't use them. Clang is a full C++ compiler. Even though LLVM & Clang do not use exceptions in their implementation, Clang does support compiling C++ code that uses exceptions. Does this answer your

Siddharth, I'm not sure what coding standards you refer to when you say "some C++ coding standard". This question is answered in the LLVM Coding Standards document here: https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions <https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions> As such LLVM's coding standards prohibit the

Hi all, Can anyone explain why exceptions are disabled in LLVM, even if some C++ coding standard tells to use exceptions ? Thanks, Siddharth -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180501/ed7903db/attachment-0001.html>

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

Hi, I'm having problems compiling llvm-gcc-4.2-2.9 (from [1]). I need to use this version because I am trying to use KLEE (see [3]) which needs these versions. I am compiling on Arch Linux using gcc (GCC) 4.7.0 20120505 (prerelease) the output of `gcc -v` can be found at http://pastebin.com/8j2m3wzD I have tried the following 1. Extracted llvm-2.9 (from [2]) 2. Applied a patch (adds

Hi all, We have enabled Thin LTO and LTO for a specific target architecture. What can be the possible scopes of improvement depending on the target after we enable the basic LTO and thin LTO.? Wanted to know the possible approach we can think to see how it performs compared to a not LTO enabled case and also what all possible directions can we think to improve upon it depending on the arch. I am