similar to: [LLVMdev] ubsan - active member check for unions

On 12/16/2014 02:43 AM, Yury Gribov wrote: > On 12/15/2014 10:24 PM, Ismail Pazarbasi wrote: >> s.d = 42.0; >> if (s.l > 100) // fire here > > Note that code like this is frequently used to convert integers to > floats so you'll get tons of false positives. True positives. The fix is to use memcpy instead. Emitting error for > accessing differently

Hello. Is it possible to set specify the font used by legend()? I would like to specify a fixed-width font so that I can line up parts of vertically stacked curve labels. For example, it would be nice if I could align the names, ages, and weights in the following three curve labels: Bob age=7 weight=100 Alexander age=13 weight=150 Susan age=20 weight=130 Is there perhaps a clever

On Thu, Dec 18, 2014 at 11:05 PM, Yury Gribov <y.gribov at samsung.com> wrote: > > On 12/19/2014 01:14 AM, Nick Lewycky wrote: > >> On 12/16/2014 02:43 AM, Yury Gribov wrote: >> >>> On 12/15/2014 10:24 PM, Ismail Pazarbasi wrote: >>> >>>> s.d = 42.0; >>>> if (s.l > 100) // fire here >>>> >>>

Hi, I've just tagged LLVM 9.0.1-rc3. Testers can begin testing and uploading binaries. This will be the last release candidate unless there is a major problem. I'm planning to tag the final release on Dec 19. -Tom

Hi, I've tagged the LLVM 9.0.1-rc1 release. Testers can begin testing and upload binaries. I've also updated the test-release.sh script to pull from GitHub instead of SVN, if you run into any issues with the new script, let me know. -Tom

Hi, I've just tagged the 9.0.1-final release. Testers can begin uploading binaries. -Tom

Hi, I've tagged LLVM 9.0.1-rc2. Testers can begin testing and uploading binaries. If all goes well, this will be the last -rc. -Tom

Hi all, TL;DR 1) We should change the way we parse common runtime flags in sanitizers. 2) We should make ASan aware of the tools it can be combined with (LSan and UBSan). 3) We may have to restrict the tools UBSan can be combined with (currently to ASan) (see [1]) Currently we have two kinds of sanitizer runtime flags: tool-specific flags and "common flags", defined in sanitizer_common

> 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

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

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

Hi All, I am first time trying build CLANG+LLVM using cmake+ninja build system. I updated all my CLANG+LLVM sources to current trunk, and I successfully built it using classic *make* build system. But, trying to build the same with cmake+ninja build system resulting in following build failures for compiler-rt sources. Am I missing something basics here? ==================== cmake command used:

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

I'm seeing this too. CC'ing the author ubsan stuff. Richard, I know you were OK with only supporting Clang-bootstraps, but I don't think that's terribly viable here. We should be able to build ubsan's runtime with standards conforming code unless there is some fairly extreme reason not to... On Fri, Oct 12, 2012 at 7:19 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote:

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

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

I use latest cmake+ninja which are built from latest sources. ================================= > cmake --version cmake version 2.8.9.20121011-g2876 ================================= -- mahesha On Fri, Oct 12, 2012 at 7:35 PM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > Hi All, > > I am first time trying build CLANG+LLVM using cmake+ninja build > system. I updated all

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

Hello everyone, 9.0.0-rc5 was just tagged from the release_90 branch at r371837. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc5. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc5 Binaries will be added as they become available. There is only a single change from rc4 to rc5. Once more, the hope is that this will be the last release candidate and that we can

On Fri, Oct 12, 2012 at 6:14 PM, Chandler Carruth <chandlerc at google.com> wrote: > I'm seeing this too. CC'ing the author ubsan stuff. > > Richard, I know you were OK with only supporting Clang-bootstraps, but I > don't think that's terribly viable here. Just out of curiosity - why isn't that viable? I'd sort of hope to treat optional sanitizer runtimes