search for: check_cxx_compiler_flag

...#39;re very happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks. When running checks like check_c_compiler_flag, check_cxx_compiler_flag or check_library_exists, CMake caches the resulting variable and doesn't run the check again. The problem is that in LLVM, each subproject uses different variable names for results of these checks. For example, most subprojects check if pthread is available and store the result in: COMPILER_RT...

...y happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks. > > When running checks like check_c_compiler_flag, check_cxx_compiler_flag or check_library_exists, CMake caches the resulting variable and doesn't run the check again. The problem is that in LLVM, each subproject uses different variable names for results of these checks. For example, most subprojects check if pthread is available and store the result in: > > C...

...with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks. >> >> When running checks like check_c_compiler_flag, check_cxx_compiler_flag or check_library_exists, CMake caches the resulting variable and doesn't run the check again. The problem is that in LLVM, each subproject uses different variable names for results of these checks. For example, most subprojects check if pthread is available and store the result in: >> &g...

...instantiations to become hidden in certain cases. The following hunk works around this... --- a/cmake/modules/HandleLLVMOptions.cmake +++ b/cmake/modules/HandleLLVMOptions.cmake @@ -159,7 +159,13 @@ endif() if(NOT WIN32 AND NOT CYGWIN) # MinGW warns if -fvisibility-inlines-hidden is used. check_cxx_compiler_flag("-fvisibility-inlines-hidden" SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG) - append_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 failure...

...xceptions -o CMakeFiles/LLVMSupport.dir/regcomp.c.o -c /Users/jabbey/src/llvmCommit/lib/Support/regcomp.c cc1: error: unrecognized command line option "-Wcovered-switch-default" The problem stems from HandleLLVMOptions.cmake where a single check of the warning option is performed using check_cxx_compiler_flag, and then upon success add_llvm_definitions appends to the flag to a list consumed by both C and CXX compilers. Attached is a patch which updates HandleLLVMOptions.cmake to: - Test C and CXX compiler separately for -Wcovered-switch-default - Split SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG into a C...

...LLVMSupport.dir/regcomp.c.o -c > /Users/jabbey/src/llvmCommit/lib/Support/regcomp.c > cc1: error: unrecognized command line option "-Wcovered-switch-default" > > The problem stems from HandleLLVMOptions.cmake where a single check of the > warning option is performed using check_cxx_compiler_flag, and then upon > success add_llvm_definitions appends to the flag to a list consumed by both > C and CXX compilers. > > Attached is a patch which updates HandleLLVMOptions.cmake to: > - Test C and CXX compiler separately for -Wcovered-switch-default > - Split SUPPORTS_COVERED_...

...ake for runtimes (i.e. where path/to/my/llvm-project/llvm/runtimes/CMakeLists.txt is the top-level one), you may not have a fully working toolchain yet. For example, in case of Fuchsia, our sysroot contains only libc, so when we're doing the runtimes build, and one of the runtimes tries to use check_cxx_compiler_flag, which behind the scenes tries to compile and link a small C++ binary, that check is going to fail not because the flag isn't supported, but because we don't have libc++ yet (that's what we're trying to build right now). So we need to be really careful and avoid introducing cycles e...

...e’re compiling for ARM, and not just any ARM, but when we’re using ARM EHABI, e. g. on Linux (AFAIU Darwin doesn’t use EHABI). But I don’t know a way to detect this at configuration time, only at build time. I have an idea of the way that we could detect the -funwind-tables flag at build time: the check_cxx_compiler_flag function in CMake sets the LIBUNWIND_SUPPORTS_${flagname}_FLAG variable. Now, if the value of that variable is true, we pass a preprocessor definition like _LIBUNWIND_HAS_UNWIND_TABLES to the compiler when building libunwind. In the libunwind source code, we check if that macro is defined, and if n...

...en SANITIZER_COMMON_CFLAGS) append_list_if(COMPILER_RT_HAS_FNO_FUNCTION_SECTIONS_FLAG -fno-function-sections SANITIZER_COMMON_CFLAGS) diff --git a/cmake/config-ix.cmake b/cmake/config-ix.cmake index 0b722c3..7cc9d1c 100644 --- a/cmake/config-ix.cmake +++ b/cmake/config-ix.cmake @@ -10,6 +10,7 @@ check_cxx_compiler_flag(-fno-exceptions COMPILER_RT_HAS_FNO_EXCEPTIONS_FLAG check_cxx_compiler_flag(-fomit-frame-pointer COMPILER_RT_HAS_FOMIT_FRAME_POINTER_FLAG) check_cxx_compiler_flag(-funwind-tables COMPILER_RT_HAS_FUNWIND_TABLES_FLAG) check_cxx_compiler_flag(-fno-stack-protector COMPILER_RT_HAS_FNO_STACK...

[Cross-post to llvm-dev to make sure everybody relevant sees this] Hi, I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of

> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: