beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Meta/CMake/common_compile_options.cmake

43 lines
1.6 KiB
CMake
Raw Normal View History

Meta: Move some flags to common_compile_options.cmake No behavior change.
2023-04-15 21:34:18 +00:00
# Flags shared by Lagom (including Ladybird) and Serenity.
Meta: Move compiler flags into standalone CMake files This way we can have all of them in a single place, similar to how we structure options added via the serenity_option() macro.
2022-05-14 13:07:12 +00:00
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
add_compile_options(-Wall)
add_compile_options(-Wextra)
Meta: Move some flags to common_compile_options.cmake No behavior change.
2023-04-15 21:34:18 +00:00
add_compile_options(-Wno-unknown-warning-option)
add_compile_options(-Wno-unused-command-line-argument)
add_compile_options(-fdiagnostics-color=always)
add_compile_options(-fno-exceptions)
Meta: Globally disable floating point contraction FP contraction is a standard-conforming behavior which allows the compiler to calculate intermediate results of expressions containing floating point numbers with a greater precision than the expression type allows. And in theory, it enables additional optimizations, such as replacing `a * b + c` with fma(a, b, c). Unfortunately, it is extremely hard to predict when the contraction will happen. For example, Clang 17 on x86_64 with the default options will use FMA only for constant-folded non-constexpr expressions. So, in practice, FP contraction leads to hard-to-find bugs and inconsistencies between executables compiled with different toolchains or for different OSes. And we had two instances of this happening last week. Since we did not ever used -mfma on x86_64, this patch can only possibly regress performance on Apple ARM devices, where FMA is enabled by default. However, this regression will likely be negligible since the difference would be one additional add instruction, which would be then likely executed in parallel with something else.
2023-11-16 19:48:32 +00:00
add_compile_options(-ffp-contract=off)
Meta: Move compiler flags into standalone CMake files This way we can have all of them in a single place, similar to how we structure options added via the serenity_option() macro.
2022-05-14 13:07:12 +00:00
if (NOT CMAKE_HOST_SYSTEM_NAME MATCHES SerenityOS)
# FIXME: Something makes this go crazy and flag unused variables that aren't flagged as such when building with the toolchain.
# Disable -Werror for now.
add_compile_options(-Werror)
endif()
Meta: Move more common flags to common_compile_options.cmake For the most part no behavior change, except that we now pass -Wno-implicit-const-int-float-conversion and -Wno-literal-suffix only to clang and gcc each in both lagom and serenity builds, while we previously passed them to both in lagom builds (and passed them to one each in serenity builds). The former is a clang flag, the latter a gcc flag, but since we also use -Wno-unknown-warning-option it doesn't really matter.
2023-04-17 23:50:53 +00:00
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang$")
# Clang's default constexpr-steps limit is 1048576(2^20), GCC doesn't have one
add_compile_options(-fconstexpr-steps=16777216)
add_compile_options(-Wno-implicit-const-int-float-conversion)
add_compile_options(-Wno-user-defined-literals)
CMake: Disable Clang 18+ `-Wvla-cxx-extension` warning This warning warns about variable-length arrays being a non-standard extension to the C++ language. We still have a few instances of VLAs, so let's disable the warning for now. This does not interfere with `-Wvla`, which we use to completely forbid this (potentially dangerous) feature in the Kernel and LibCrypto.
2023-11-05 17:04:23 +00:00
add_compile_options(-Wno-vla-cxx-extension)
Meta: Move more common flags to common_compile_options.cmake For the most part no behavior change, except that we now pass -Wno-implicit-const-int-float-conversion and -Wno-literal-suffix only to clang and gcc each in both lagom and serenity builds, while we previously passed them to both in lagom builds (and passed them to one each in serenity builds). The former is a clang flag, the latter a gcc flag, but since we also use -Wno-unknown-warning-option it doesn't really matter.
2023-04-17 23:50:53 +00:00
elseif (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
# Only ignore expansion-to-defined for g++, clang's implementation doesn't complain about function-like macros
add_compile_options(-Wno-expansion-to-defined)
add_compile_options(-Wno-literal-suffix)
Everywhere: Make Lagom build with GCC 13 GCC 13 was released on 2023-04-26. This commit fixes Lagom build errors when using an updated host toolchain: - Adds a workaround for a bug in constraint handling, which made LibJS fail to compile: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109683 - Silences the new `-Wdangling-reference` diagnostic globally. It produces multiple false positives with no clear way to silence them without `#pragmas`. - Silences `-Wself-move` in `RefPtr` tests as GCC 13 adds this previously Clang-exclusive warning.
2023-05-01 14:59:46 +00:00
# FIXME: This warning seems useful but has too many false positives with GCC 13.
add_compile_options(-Wno-dangling-reference)
Meta: Move more common flags to common_compile_options.cmake For the most part no behavior change, except that we now pass -Wno-implicit-const-int-float-conversion and -Wno-literal-suffix only to clang and gcc each in both lagom and serenity builds, while we previously passed them to both in lagom builds (and passed them to one each in serenity builds). The former is a clang flag, the latter a gcc flag, but since we also use -Wno-unknown-warning-option it doesn't really matter.
2023-04-17 23:50:53 +00:00
endif()
CMake: Set `-fvisibility-inlines-hidden` on ELF platforms The C++ semantics of `inline` dictate that such functions might be defined in multiple translation units. As with all other functions, they must have the same address in all TUs. Because of this, the compiler emits `inline` functions as weak symbols, which the dynamic linker can then resolve to the same address everywhere. This rule is responsible for a significant overhead at startup, as such lookups happen by name. Namely, 86'000 of the 114'000 by-name symbol lookups when loading LibWeb can be attributed to this. Most of these are only ever defined in a single object, making this even more pointless. As nothing in our code relies on either ELF symbol interposition rules or function address equality, we can use the -fvisibility-inlines-hidden escape hatch, which causes this rule to be disregarded. As the symbols are now hidden, no load-time symbol lookup is needed. This flag is used without issues in other large C++ codebases like Chromium and LLVM. Some relevant light reading, suggested by Nico: - https://ridiculousfish.com/blog/posts/i-didnt-order-that-so-why-is-it-on-my-bill-episode-1.html - https://www.cs.dartmouth.edu/~sergey/cs258/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf - https://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html - https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fvisibility-inlines-hidden
2023-08-11 22:40:34 +00:00
if (UNIX AND NOT APPLE AND NOT ENABLE_FUZZERS)
add_compile_options(-fno-semantic-interposition)
add_compile_options(-fvisibility-inlines-hidden)
endif()
Reference in a new issue Copy permalink