search for: llvm_enable_abi_breaking_checks

...initializer calling the >> runtime check. The symbol name would be different if the ABI break is >> enabled or not. > > Can it be made into a link-time check instead? I'm imagining something like: I’d love to, but didn’t find a universal solution unfortunately :( > #if LLVM_ENABLE_ABI_BREAKING_CHECKS > extern int EnableABIBreakingChecks; > __attribute__((weak)) int *VerifyEnableABIBreakingChecks = &EnableABIBreakingChecks; > #else > extern int DisableABIBreakingChecks; > __attribute__((weak)) int *VerifyDisableABIBreakingChecks = &VDisableABIBreakingChecks; > #en...

...ded 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 matches LLVM's. In the long > run, we could conceivably do something with LLVM_ENABLE_ABI_BREAKING_CHECKS > to allow this mismatch. > In practice it is very hard to make NDEBUG flag match configs of your project and LLVM project. You often need to build debug and release versions of your project and LLVM is installed as a debian package or with homebrew. Moreover, there is not reliable way of ch...

...efforts to make LLVM's ABI resilient to > mismatched > > NDEBUG definitions between LLVM and its users. > > > > For now, make sure your definition of NDEBUG matches LLVM's. In the > long > > run, we could conceivably do something > > with LLVM_ENABLE_ABI_BREAKING_CHECKS to allow this mismatch. > > > > In practice it is very hard to make NDEBUG flag match configs of your > project > > and LLVM project. You often need to build debug and release versions of > your > > project and LLVM is installed as a debian package or with homebrew. &g...

...vm/Config/llvm-config.h.cmake +++ b/llvm/include/llvm/Config/llvm-config.h.cmake @@ -80,4 +80,18 @@ /* LLVM version string */ #define LLVM_VERSION_STRING "${PACKAGE_VERSION}" + +#ifdef __cplusplus +namespace llvm { +bool setABIBreakingChecks(bool Enabled); +__attribute__((weak)) +#if LLVM_ENABLE_ABI_BREAKING_CHECKS +bool +ABICheckEnabled = setABIBreakingChecks(true); +#else +bool ABICheckDisabled = setABIBreakingChecks(true); +#endif +} +#endif + #endif diff --git a/llvm/lib/Support/Error.cpp b/llvm/lib/Support/Error.cpp index 7436a1fd38ee..151fcdcbfb27 100644 --- a/llvm/lib/Support/Error.cpp +++ b/llvm/lib/...

...I'm not sure there is a good way of doing this, but we could certainly have a build mode which does this (and a buildbot running with that mode). I suspect we don't want to do this based on NDEBUG anyway to avoid ODR problems from external client code. It would be possible to base this on LLVM_ENABLE_ABI_BREAKING_CHECKS instead of NDEBUG (there's a CMake option to control this). - Asserts builds -DLLVM_ENABLE_ABI_BREAKING_CHECKS by default. - No-asserts builds -ULLVM_ENABLE_ABI_BREAKING_CHECKS by default. - Clients that mix-and-match Asserts/No-asserts can pick one or the other. > > -Hal > >>...

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

...d > > > NDEBUG definitions between LLVM and its users. > > > > > > For now, make sure your definition of NDEBUG matches LLVM's. > In the > > long > > > run, we could conceivably do something > > > with LLVM_ENABLE_ABI_BREAKING_CHECKS to allow this mismatch. > > > > > > In practice it is very hard to make NDEBUG flag match configs of > your > > project > > > and LLVM project. You often need to build debug and release > versions of > > your > > > projec...

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

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.