Displaying 6 results from an estimated 6 matches for "uppercase_cmake_build_typ".
Did you mean:
uppercase_cmake_build_type
2017 Oct 04
3
Question: Should we consider valid a variable defined #ifndef NDEBUG scope and used in assert?
...his happens in include/llvm/IR/ValueHandle.h for the variable Poisoned line 494
This works because when we build LLVM with assert we explicitly disable NDEBUG:
if( LLVM_ENABLE_ASSERTIONS )
[…]
# On non-Debug builds cmake automatically defines NDEBUG, so we
# explicitly undefine it:
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
add_definitions( -UNDEBUG )
If we use this header in a different project and thus, with potentially different rules for macro definitions, the compiler complains with
error: use of undeclared identifier ‘Poisoned'
I think the right thing to do is to fix the...
2017 Oct 04
2
Question: Should we consider valid a variable defined #ifndef NDEBUG scope and used in assert?
...eHandle.h for the variable Poisoned line 494
>
> This works because when we build LLVM with assert we explicitly disable NDEBUG:
> if( LLVM_ENABLE_ASSERTIONS )
> […]
> # On non-Debug builds cmake automatically defines NDEBUG, so we
> # explicitly undefine it:
> if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
> add_definitions( -UNDEBUG )
>
> If we use this header in a different project and thus, with potentially different rules for macro definitions, the compiler complains with
> error: use of undeclared identifier ‘Poisoned'
>
> I think the r...
2016 Jun 19
2
Linker failures in debug build - compiler/linker poll?
...if(SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG
"-fvisibility-inlines-hidden" CMAKE_CXX_FLAGS)
+
+ # The flag also hides inlines from explicit template instantiations,
which
+ # leads to link failures in debug builds at least with gcc 5.3.1 and
+ # both GNU ld 2.26 or gold 1.11.
+ if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
+ append_if(SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG
"-fvisibility-inlines-hidden" CMAKE_CXX_FLAGS)
+ endif()
endif()
if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
... but before I just wildly commit something, I'd say this does seem more
like a...
2012 Jul 07
0
[LLVMdev] Crash using the JIT on x86 but work on x64
Hi Skykill,
> Hello everyone, i’m using LLVM (updated to 3.1 after seeing that bug, but it’s
> the same with 3.0) for running a bitcode on a C++ program, and Clang for
> compiling it. My code work perfectly, as expected on x64, but crash on x86. I’m
> on Windows 7 x64 and LLVM + Clang was compiled using Visual Studio 2010 (tested
> in both Release and Debug build). Project was make
2012 Jul 07
2
[LLVMdev] Crash using the JIT on x86 but work on x64
Hi, so yes assertions are enabled by default in Debug from what i could see
in the CMakeLists.txt
if( uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE" )
option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF)
else()
option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON)
endif()
Without assertions enabled, when i'm running the program without the
debugger, it simply freeze until i close it,...
2012 Jul 07
2
[LLVMdev] Crash using the JIT on x86 but work on x64
Hello everyone, i’m using LLVM (updated to 3.1 after seeing that bug, but it’s the same with 3.0) for running a bitcode on a C++ program, and Clang for compiling it. My code work perfectly, as expected on x64, but crash on x86. I’m on Windows 7 x64 and LLVM + Clang was compiled using Visual Studio 2010 (tested in both Release and Debug build). Project was make using CMake.
Here is my code: