similar to: [8.0.0 Release] Need help with PR40761: Sanitizers broken on FreeBSD

That's excellent! I think the check-sanitizer target should cover it. Thanks, Hans On Fri, Feb 22, 2019 at 1:34 PM Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Hans, > > I have a freebsd machine and some time to spare this weekend. > > Could you offer the minimal git bisect command to repro? I'm hoping not to have to run the full check-clang test suite if

Many thanks for digging into this, and sorry for my slow reply. Kamil: it sounds like your commit is involved here. Any idea what's happening? Dimitry: If we don't find anyone to debug and fix this before the release, how bad is it for FreeBSD? Can it be worked around downstream if 8.0.0 ships without a fix? Since I'm not entirely sure how supported this functionality is on FreeBSD,

Hi Michael, On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). There are known problems with running IWYU over LLVM/Clang -- Zachary Turner made an attempt a while back to get it up and running.

On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi Kim, > > On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Michael, > > On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin > <mzolotukhin at apple.com> wrote: > > > Nice to IWYU developers here:) I wonder how

I did some more extensive testing and found that all GCCs older than 7 trigger the warning, but only if CMAKE_BUILD_TYPE=Release (which I guess indicates optimizations are enabled). There's a patch up for disabling the warning here: https://reviews.llvm.org/D50607. I still feel a little uncomfortable, because I think Jonathan makes an excellent point -- if GCC thinks there's a

On 08/12/2018 02:19 PM, Kim Gräsman wrote: > I still feel a little uncomfortable, because I think Jonathan makes an > excellent point -- if GCC thinks there's a strict-aliasing violation > (whether the standard agrees or not) and classifies this as undefined > behavior, we might invoke the optimizers wrath. The warning is a nice > hint that this could happen. Indeed. And

On Tue, 14 Aug 2018 at 11:56, Kim Gräsman <kim.grasman at gmail.com> wrote: > > On Tue, Aug 14, 2018 at 11:51 AM Andrew Haley <aph at redhat.com> wrote: > > > > On 08/12/2018 02:19 PM, Kim Gräsman wrote: > > > I still feel a little uncomfortable, because I think Jonathan makes an > > > excellent point -- if GCC thinks there's a strict-aliasing

I'm a little late to the party, but one observation that I haven't seen mentioned is that simply removing #includes and testing that the program compiles is not guaranteed to be a correct transformation. Imagine, for example, that a header file provides an overload of a function that is a better match than one found elsewhere. It will compile either way, but without the #include, you

Author of the problematic code here. Thanks everyone, and sorry to have caused difficulty! Obviously if there really is something illegal here we should fix it in LLVM, but it looks like this warning is a false positive (anyone disagree?) Still if there's a simple source-level workaround, or we can suppress the warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a supported

json::Value in JSON.h is a discriminated union. The storage is a char array of appropriate type and alignment. The storage holds one object at a time, it's initialized (and for nontrivial types, destroyed) at the right times to ensure this. The cast is only to the type of object that's already there, there's no magic here. On Fri, Aug 10, 2018, 17:52 Andrew Haley <aph at

Hi, I've tagged the 8.0.1-rc4 release, please begin testing. This will (hopefully) be the last release candidate. If all goes well, I will tag the final release next Wednesday. -Tom

Hans, I'd like to make sure that I'm using the right LLVM version. I tried to download LLVM 8 from the link in your email by cloning this repository: git clone https://github.com/llvm/llvm-project.git When I do llc --version, it says LLVM 9.0.0 instead of 8.0.0 LLVM (http://llvm.org/): LLVM version 9.0.0svn DEBUG build with assertions. Default target: x86_64-unknown-linux-gnu

cmake ../llvm/ -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_INSTALL_PREFIX=../install -DLLVM_TARGETS_TO_BUILD="XXX" -DLLVM_ENABLE_PROJECTS='lld;clang;' ________________________________ From: Hans Wennborg <hans at chromium.org> Sent: Thursday, March 21, 2019 2:21 AM To: Josh Sharp Cc: Brian Cain; via llvm-dev Subject: Re: [llvm-dev] LLVM 8.0.0

Thanks, Brian I tried enabling both the lld and the clang projects by adding -DLLVM_ENABLE_PROJECTS='lld;clang' into the cmake command. After the build completed successfully, I can see ld.lld in my bin folder but not clang. Is it supposed to be in another folder? Thanks. ________________________________ From: Brian Cain <brian.cain at gmail.com> Sent: Wednesday, March 20, 2019

On Thu, 9 Aug 2018 at 22:59, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Thanks all for pitching in to help! > > On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall <sam.mccall at gmail.com> wrote: > > > > Obviously if there really is something illegal here we should fix it in > > LLVM, but it looks like this warning is a false positive (anyone disagree?)

Hey Anastasia, all, There's a long-standing CMake issue with the Debian packaging for Clang (LLVM works), described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862328 I've done some debugging and have a good idea of what should be done, I just don't know enough about Debian packaging details and testing to make much progress. I'd love to hack on this with

Hi, I've been trying to burn down the remaining sanitizer failures under the new pass manager. Right now I'm stuck on some ASan tests. Some ASan tests run under -O1. There are a couple differences between the old and new pass managers under -O1, e.g. the old PM doesn't inline whereas the new PM does. The differences seem to cause some lifetime intrinsics to get stripped out (e.g. via

Just tested it out, that test does indeed fail under the old PM at -O3 and even at -O2. If the ASan pass runs after optimizations and is designed to detect undefined behavior at runtime, I don't see how it can be super reliable at higher optimization levels. On Wed, May 13, 2020 at 12:39 PM David Blaikie <dblaikie at gmail.com> wrote: > +some sanitizer/new pass manager folks >

Hi LLVM people, Not sure whether this is the best place to ask this. Given the source of a program, I would like to detect both uninitialized reads and out-of-bounds memory accesses. The latter can be done with the Address Sanitizer (ASan) and the first using the Memory Sanitizer (MSan). Is there a way to use both at the same time? The --fsanitize option only seems support one of these. What is

On Fri, Jan 31, 2014 at 1:47 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 31 January 2014 08:50, Alexey Samsonov <samsonov at google.com> wrote: > >> That is, I still don't see what the problem is - it's relatively easy to >> enable building just the compiler-rt library on ARM and not enable building >> sanitizers on ARM. >> > >