similar to: When is a store not (memory) safe?

Hi, The 6.0.1-rc2 release has been tagged. Testers may begin testing and reporting results. -Tom

Hi, I've just tagged the 6.0.1-rc1 release. Testers may begin testing and uploading binaries. Also, any tester who has not tested 5.0.2-rc1 and would like to do so please try to do this before Friday, because I would like to tag 5.0.2-final then. As a reminder to users and developers, May 18 is the deadline for submitting merge requests for 6.0.1, so there is still time to get bug fixes

Dear testers, 5.0.0-rc1 has just been tagged. Please build, test and upload binaries to the sftp. Let me know if there are any issues. I'll upload sources, docs, and your binaries to the pre-release website once they're ready. Thanks, Hans

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>

On 31 Jul 2017, at 19:26, Hans Wennborg <hans at chromium.org> wrote: > > On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: >> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >>> >>> 5.0.0-rc1 has just been tagged. >>> >>> Please build, test and upload binaries

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: > On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >> >> 5.0.0-rc1 has just been tagged. >> >> Please build, test and upload binaries to the sftp. Let me know if >> there are any issues. > > Built and tested rc1. Test failures on

Dear all, I want to implement a pass that provides some kind of data flow integrity similar to Write Integrity Testing (https://www.doc.ic.ac.uk/~cristic/papers/wit-sp-ieee-08.pdf). This approach statically determines for each memory write the (conservative, overapproximated) points-to set of locations that can be written by the instruction. Further, it instruments the memory write instruction

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > 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. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

Hello, I have been working on porting ASan to AArch64. I am building compiler-rt in "standalone mode" targeting aarch64. My build is successful, but I get the following runtime error when I run an ASan enabled executable through qemu-aarch64: ==29184==Parsed ASAN_OPTIONS: verbosity=1 ==29184==AddressSanitizer: failed to intercept '__isoc99_printf' ==29184==AddressSanitizer:

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 Alexey, >From: Alexey Zhikhartsev [..] > We would love to see your patches merged as soon as possible, so I was wondering: do you think the lack of bitcode support will prevent that from happening? Yes, I think that the lack of bitcode support will prevent it. During the Developers meeting, I also talked with Hal and Johannes. They had some extra remarks: - (1) the restrict

Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov> [..] > On 11/06, Jeroen Dobbelaere wrote: > > >From: Alexey Zhikhartsev > > [..] > > > We would love to see your patches merged as soon as possible, so I was > wondering: do you think the lack of bitcode support will prevent that from > happening? >

Dear R-group, I am trying desperately to get this Tukey test working. Its my first time here so I hope my question is not too stupid, but I couldn't find anything helpful in the help or in the forum. I am analysing a dataset of treated grasses. I want to find out, if the grasses from different Provenances react differently. In the aov test I found a significance for the combination Treatment

Nick, Have you noticed that llvm/clang svn produces the following linker warnings on 'make check-all'? Linking CXX executable Debug/AsanTest ld: warning: direct access in llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak symbol vtable for llvm::convertible_fwd_ostream means the weak symbol cannot be overridden at runtime. This was likely caused by different

Hi, Jack! On Fri, Nov 2, 2012 at 6:18 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Have you noticed that llvm/clang svn produces the following linker > warnings on > 'make check-all'? > > Linking CXX executable Debug/AsanTest > ld: warning: direct access in > llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak >

Hi, everyone, We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics. We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):

Hello again, The tool we announced 1.5 months ago has matured quite a bit. In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs: http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html Question to the LLVM developers: would you

Hello, We've just released the first version of our LLVM-based address sanity checker: AddressSanitizer (http://code.google.com/p/address-sanitizer/). The tool finds out-of-bound and use-after-free bugs (the subset of bugs detectable by Valgrind/Memcheck); it consists of a LLVM compiler plugin which performs simple code instrumentation and a malloc replacement library. The main advantage of