similar to: [RFC] Runtime checks for ABI breaking build of LLVM

> On Nov 16, 2016, at 12:05 PM, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > > > > On 11/16/16 11:48 AM, Mehdi Amini via llvm-dev wrote: >> Hi all, >> >> An issue that come up from time to time and has cost hours for debug for >> many of us and users of LLVM is that an assert build isn’t ABI >> compatible with a release build.

Hi, when using the "Debug" build of LLVM 8.0 my application which uses the LLVM builder and MCJIT components fails at startup with: symbol lookup error: ./main: undefined symbol: _ZN4llvm23EnableABIBreakingChecksE (unmangled: llvm::EnableABIBreakingChecks) The application works fine with the "Release" build of LLVM 8.0! (Right now, I need the Debug build for access to

I cannot reproduce this error, but this could be real. David, is this reproducible every time or is this flaky? On Mon, Jan 7, 2019 at 5:03 PM Heejin Ahn via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello David, > > I use x86_64 and it works on my machine. I also can't find this error on > LLVM buildbot page. I'd appreciate if you help me reproduce the problem.

On Tue, Dec 13, 2016 at 4:57 PM, Grang, Mandeep Singh via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Everyone, > > The following patch to reverse iterate SmallPtrSet's has now been merged: > https://reviews.llvm.org/D26718 > > This is how LLVM behavior will change due to this patch: > - In LLVM builds with assertions enabled, SmallPtrSet's would always be

Hi everyone, we have several header files in which the NDEBUG macro is being used. In some of these, the NDEBUG macro changes the size, the interface, or the layout of a type. One example is AssertingVH, which turns into a flat, transparent Value* wrapper in Release build. Now everywhere you use these headers, the state of the NDEBUG flag must be the same, or else bad things could happen. This

On Tue, Dec 13, 2016 at 6:39 PM, Hans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 13, 2016 at 4:57 PM, Grang, Mandeep Singh via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Everyone, >> >> The following patch to reverse iterate SmallPtrSet's has now been merged: >> https://reviews.llvm.org/D26718 >> >> This is how LLVM

I can confirm that the issue has been caused by NDEBUG flag. On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > The layout of AssertingVH has depended on NDEBUG since 2009, which > predates any of our efforts to make LLVM's ABI resilient to mismatched > NDEBUG definitions between LLVM and its users. > > For now, make sure your definition of NDEBUG

On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009,

Everyone, The following patch to reverse iterate SmallPtrSet's has now been merged: https://reviews.llvm.org/D26718 This is how LLVM behavior will change due to this patch: - In LLVM builds with *assertions enabled*, SmallPtrSet's would always be reverse iterated by default. This default behavior can be overridden via the flag "-mllvm -reverse-iterate=<true/false>".

Everyone, There is non-determinism in LLVM codegen in the following scenarios: 1. Between back-to-back runs of the same LLVM toolchain 2. Between Release vs Release+Asserts toolchains 3. Between Linux vs Windows toolchains The main reasons for the non-determinism in codegen are: 1. Iteration of unordered containers (like SmallPtrSet, DenseMap, etc) where the iteration order is undefined 2.

On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: [ brutal-snip ] ... > [ TODO#S: Before doing a 2nd build (and in a 3rd run using more > optimized binaries) ] > > How do I anable LTO via CMAKE? > > > LLVM_ENALBLE_LTO=On > [ v4 of my build-script attached ] Hi Chris, thanks for the response! That seems to work (see below). $ cd

> On 2016-Nov-15, at 15:16, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Mandeep Singh via llvm-dev Grang" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "mehdi amini" <mehdi.amini at apple.com>, dexonsmith at apple.com, zinob at codeaurora.org >> Sent: Tuesday, November 15, 2016

Hi, I have problem with IRBuilderBase::InsertPointGuard class that simply does not work in the release build of my project. The class does not restore the IRBuilder's insert point correctly when NDEBUG macro is set. It happens on OSX system only, trunk version of the LLVM built with brew. I suspect it is the ABI problem. InsertPointGuard uses AssertingVT for debug builds. LLDB gets confused

On 2020-04-10, Michael Kruse via llvm-dev wrote: >#ifndef NDEBUG in the LLVM source and assert() are at least somewhat >linked. For instance, consider >https://github.com/llvm/llvm-project/blob/8423a6f36386aabced2a367c0ea53487901d31ca/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp#L2668 > >The #ifndef NDEBUG is used to guard the value that checked in an >assert() later. Only

Trying to run a self host "ninja check-clang" with ASan enabled I hit a /lot/ of errors like this (strangely I hit none of these in check-llvm, only in check-clang): Any ideas? ==10525==ERROR: AddressSanitizer failed to deallocate 0x10800 (67584) bytes at address 0x631000014800 ==10525==AddressSanitizer CHECK failed:

On Sun, Jul 9, 2017 at 1:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Sun, Jul 9, 2017 at 9:19 AM, Jack Howarth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> FYI, I just successfully performed a 3-stage bootstrap with >> stage2/stage3 object file comparison on x86_64-apple-darwin16 for >>

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

I wish there was something like the line in config.log that would show the CMake command, but instead I can at least show you the CMakeCache files for my release build and asan build (attached to this email). No lld, so far as I know - believe I'm using gold at the moment for both builds. Did just reproduce this with a clean release build and a clean asanified build from that. Same errors. I

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the