similar to: Where does the LLVM implement the Ubsan's instrumentations?

> On Jul 21, 2017, at 6:04 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >>> I think your best bet for controlling code bloat is to compile with >>> -fsanitize=undefined -fsanitize-trap=undefined. >> >> Also you may not need all of UBSan's checks at the same time -- so pick >> and choose among its checks using the

> I think your best bet for controlling code bloat is to compile with > -fsanitize=undefined -fsanitize-trap=undefined. Also you may not need all of UBSan's checks at the same time -- so pick and choose among its checks using the finer-grained flags. If you're really stuck against a hard limit on code size, try applying UBSan to a subset of files in your project at a time. John

> On Mar 19, 2018, at 3:44 PM, Brian Gesiak <modocache at gmail.com> wrote: > > Hello all! > (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) > > I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. >

Hello all! (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. You can see an example of the assert in this 26-line C++ file here: https://godbolt.org/g/Gw9UZq Note that

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).

(+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

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

Dear All, I'm trying to implement the section of the manual pertaining to the gcc-ubsan test carried by CRAN on my local computer (ubuntu 14.04): http://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/README.txt I was wondering whether someone could tell what the minimal version of the gcc tool chain needed to run the gcc-ASAN and gcc-UBSAN alignment tests on ones local

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,

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

CRAN has a package of mine in upload limbo because it failed UBSAN. I am not entirely ignorant on the topic of sanitizers and SAN / ASAN / UBSAN; we created not one but two Docker containers with ASAN and USBAN: https://registry.hub.docker.com/u/rocker/r-devel-san/ https://registry.hub.docker.com/u/rocker/r-devel-ubsan-clang/ as well as predecessors to them in earlier Docker repos. Yet I

X32 support patch for compiler-rt. Applies against current trunk. --- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21 06:27:38.000000000 +0000 +++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21 11:16:55.891621025 +0000 @@ -41,7 +41,18 @@ SupportedArches += x86_64 endif else - SupportedArches := x86_64 + # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit

Thanks John, seems like a dynamic runtime instrumentation is then not a good idea. I had a look at the UBSan features in Clang and I might be able to use them instead. But it seems like that vector operations are not instrumented with overflow checks if I specify the option -fsanitize=signed-integer-overflow. Am I missing some other option or is there a special reason why vector operations are not

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

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

Hi Manuel, I believe you're maintaining Phabricator at reviews.llvm.org <http://reviews.llvm.org/>. Duncan likes to send his patch comments via email, like in the example below. Do you know why don't his replies get imported into the web interface? The reply was sent to "reviews+D24569+public+a5763c0a090df06f at reviews.llvm.org

> 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

Sorry, lost track of this thread. On Wed, Feb 17, 2016 at 8:45 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Fri, Feb 12, 2016 at 5:43 PM, Alexey Samsonov <vonosmas at gmail.com> > wrote: > >> >> >> On Thu, Feb 11, 2016 at 1:50 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> >>> >>>

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

Dear all, bigKRLS, which has been on CRAN for a couple of years, had to be pulled recently due to what seems to be a sanitizer issue stemming from its use of bigmemory. bigKRLS works fine (we?ve used it ourselves on many different platforms and have had over 15,000 downloads without an end user reporting difficulties because of this issue). Unfortunately, we have been unable to reproduce the