search for: cmake_cxx_flags_release

...> NDEBUG. > > > > FWIW, `llvm-config --assertion-mode` will tell you whether or not > your > > LLVM was built with or without NDEBUG. > > > > That's not true in all cases. In case CMAKE_BUILD_TYPE=Release, > > LLVM_ENABLE_ASSERTIONS=Off and CMAKE_CXX_FLAGS_RELEASE="" llvm-config > reports > > asserts as off but NDEBUG flag is not set. > > Um, okay, but why would you set CMAKE_CXX_FLAGS_RELEASE=""? That doesn't > make any sense... > I agree, it make no sense. But homebrew actually does that: https://github.com/Hom...

Hey Pete, I also tried CMAKE_CXX_FLAGS_RELEASE with the same effect. On Mon, Jul 20, 2015, at 09:34 AM, Pete Cooper wrote: > Hi Adrian > > I’m not sure if the CMAKE_CXX_FLAGS is used in LLVM. We have our own > flags for different configurations. I don’t remember if our ones inherit > from CMAKE_CXX_FLAGS or override it comple...

...hecking if LLVM has been built with or > without > > NDEBUG. > > FWIW, `llvm-config --assertion-mode` will tell you whether or not your > LLVM was built with or without NDEBUG. > That's not true in all cases. In case CMAKE_BUILD_TYPE=Release, LLVM_ENABLE_ASSERTIONS=Off and CMAKE_CXX_FLAGS_RELEASE="" llvm-config reports asserts as off but NDEBUG flag is not set. > > > Can I do anything more about it? Contributions related to > > LLVM_ENABLE_ABI_BREAKING_CHECKS needed? > > > > - Paweł > > > > _______________________________________________ &...

...agate flags to build Adrian, What makes you think CMAKE_CXX_FLAGS isn’t being respected? The tests will always occur regardless of whether or not you set the CXX_FLAGS explicitly. -Chris > On Jul 20, 2015, at 9:36 AM, adek at adek.io wrote: > > > Hey Pete, > > I also tried CMAKE_CXX_FLAGS_RELEASE > with the same effect. > > On Mon, Jul 20, 2015, at 09:34 AM, Pete Cooper wrote: >> Hi Adrian >> >> I’m not sure if the CMAKE_CXX_FLAGS is used in LLVM. We have our own >> flags for different configurations. I don’t remember if our ones >> inherit from...

...s will always occur regardless of whether or not you set the > > CXX_FLAGS explicitly. > > > > -Chris > > > > > On Jul 20, 2015, at 9:36 AM, adek at adek.io wrote: > > > > > > > > > Hey Pete, > > > > > > I also tried CMAKE_CXX_FLAGS_RELEASE > > > with the same effect. > > > > > > On Mon, Jul 20, 2015, at 09:34 AM, Pete Cooper wrote: > > >> Hi Adrian > > >> > > >> I’m not sure if the CMAKE_CXX_FLAGS is used in LLVM. We have our own > > >> flags for different...

'-DCMAKE_CXX_FLAGS=-fno-omit-frame-pointer -Wno-maybe-uninitialized -fPIC -fPIE' -- The C compiler identification is GNU 4.8.1 -- The CXX compiler identification is GNU 4.8.1 -- Check for working C compiler: /home/engshare/third-party2/gcc/4.8.1/centos6-native/cc6c9dc/bin/gcc -- Check for working C compiler: /home/engshare/third-party2/gcc/4.8.1/centos6-native/cc6c9dc/bin/gcc -- works --

On Tue Nov 17, 2020 at 6:37 PM GMT, Min-Yih Hsu wrote: > Just trying to understand: Are you suggesting a way to have a “-O0” > build without all the debug information? > Exactly.

Hi Renato, If Kristof is busy I can make runs on AArch64 Linux (Cortex-A53 and Cortex-57). Thanks, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Renato Golin via llvm-dev > Sent: Thursday, March 30, 2017 9:54 AM > To: Quentin Colombet > Cc: llvm-dev;

...es LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build type). It also automatically detects which CRT was already chosen by CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to those values. (Before, it was using add_llvm_definitions(), which worked...somehow, but CMAKE_CXX_FLAGS_RELEASE and friends were still defining their own CRT flag. Now it edits the FLAGS variables instead.) -------------- next part -------------- A non-text attachment was scrubbed... Name: add-build-config-crt-selection-v4.patch Type: text/x-patch Size: 4950 bytes Desc: not available URL: <http://lists.ll...

...ww.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F > + foreach(flag_var > + CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO > + CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO) > + if(${flag_var} MATCHES "/MD") > + string(REGEX REPLACE "/MD" "/${LLVM_USE_CRT}" ${flag_var} "${${flag_var}}") > + endif(${flag_var} MATCHES "/MD") > +...

...; build without all the debug information? > > > Exactly. What is such a build useful for the average user? If changing the default, I think that CMAKE_BUILD_TYPE=Release is what most non-developer users want. You mention CI systems, but I'd expect CI maintainers to know they can set CMAKE_CXX_FLAGS_RELEASE. Does -O0 even build faster than -O1? Michael

...e absense of a value. Perhaps we could find a middle ground. e.g. LLVM_DONT_TWEAK_CMAKES_BUILD_TYPE=ON which would allow fast builds, but also enable us to mess with the cmake default to please new users? > > You mention CI systems, but I'd expect CI maintainers to know they can > set CMAKE_CXX_FLAGS_RELEASE. Does -O0 even build faster than -O1? On my configuration, yes: -O1 is slower than -O0 $ cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS_RELEASE=-O1 -GNinja -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ... $ time ninja llc [1199/1199] Linking...

...le-use') # XXX: TRYOUT #4: Use optimized tablegen # ### TRYOUT #1: GOLD <--- DONE # CMAKE_LINKER:FILEPATH=/usr/bin/ld # GOLD_EXECUTABLE:FILEPATH=/usr/bin/ld.gold # LLVM_TOOL_GOLD_BUILD:BOOL=ON # ### TRYOUT #2: OPTLEVEL '-O3' <--- NOP # CMAKE_ASM_FLAGS_RELEASE:STRING=-O3 -DNDEBUG # CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG # CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG # ### TRYOUT #3: LTO AND PGO <--- UNSURE # LLVM_TOOL_LLVM_LTO_BUILD:BOOL=ON # LLVM_TOOL_LTO_BUILD:BOOL=ON # LLVM_USE_OPROFILE:BOOL=OFF # #### TRYOUT #4: TABLEGEN # LLVM_OPTIMIZED_TABLEGEN:BOOL=OFF # ##### END *** SECTION WILL BE DEL...

...SE_CRT_RELEASE, etc (one for each build > type). It also automatically detects which CRT was already chosen by > CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to > those values. > > (Before, it was using add_llvm_definitions(), which worked...somehow, > but CMAKE_CXX_FLAGS_RELEASE and friends were still defining their own > CRT flag. Now it edits the FLAGS variables instead.) I'm a bit wary about this patch. So much complexity for so petty feature... Maybe the right thing is to determine the scenarios where people set LLVM_USE_CRT. Maybe all we need is to define anot...

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

Attached are two patches with MSVC build enchancements. They are quite trivial, but were necessary to correctly link LLVM libraries with Mesa3D on Windows. Jose -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL:

...M an own linker? Can be used? Speedup the build? Yesterday night I loooked through available CMAKE/LLVM variables... ### GOLD # CMAKE_LINKER:FILEPATH=/usr/bin/ld # GOLD_EXECUTABLE:FILEPATH=/usr/bin/ld.gold # LLVM_TOOL_GOLD_BUILD:BOOL=ON ### OPTLEVEL # CMAKE_ASM_FLAGS_RELEASE:STRING=-O3 -DNDEBUG # CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG # CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG ### LTO # LLVM_TOOL_LLVM_LTO_BUILD:BOOL=ON # LLVM_TOOL_LTO_BUILD:BOOL=ON ### PGO # LLVM_USE_OPROFILE:BOOL=OFF #### TABLEGEN # LLVM_OPTIMIZED_TABLEGEN:BOOL=OFF So '-O3' is default for a RELEASE build. Not sure which of the LTO...

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

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 Mar 2, 2016, at 4:22 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > I got some more inspirations on how to speedup my build and integrated > the URLs into my scripts (attached). > > For example to use GOLD as linker or to use '-O3' OptLevel maybe in > combination with LTO and PGO (using '-O3 -flto -fprofile-use'). LTO *will* slow down