Refreshing package.cflags for LLVM/Clang >= 13
Over the (much too quick, can someone make time slow down?) couple of years, there have been several fixes or implementations within the LLVM toolchain that warrants review of our current flag filters. This is a WIP as I am currently rebuilding my LLVM related packages and testing them. I will edit when I have more time soon.
I plan on making pull requests for portage-bashrc-mv as well since we all use it, but I suppose more testing is required.
NOTE: For this issue, unless otherwise stated, I have my env set up to use clang-13, lld-13, llvm-13, and friends. I have also removed the filters in bashrc.d/10-flag.sh and package.cflags/* to allow using filtered flags.
$ cat /etc/portage/env/llvm.conf
CC="clang"
CXX="clang++"
AR="llvm-ar"
NM="llvm-nm"
RANLIB="llvm-ranlib"
LD="ld.lld"
CFLAGS="-march=native -O3 -fno-plt -fno-semantic-interposition -pipe"
CXXFLAGS="-march=native -O3 -fno-plt -fno-semantic-interposition -pipe"
LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed"
I have set the build to use -flto with -DLLVM_ENABLE_LTO=Thin
After configuring, this what was given:
Build type RelWithDebInfo
Install path /usr/lib/llvm/13
Compiler flags:
C -march=native -O3 -fno-plt -fno-semantic-interposition -pipe -fno-finite-math-only -fPIC -fno-semantic-interposition -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin
C++ -march=native -O3 -fno-plt -fno-semantic-interposition -pipe -fno-finite-math-only -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin
Linker flags:
Executable -Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,--color-diagnostics -flto=thin
Module -Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,-z,nodelete -Wl,--color-diagnostics
Shared -Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,-z,defs -Wl,-z,nodelete -Wl,--color-diagnostics -flto=thi
$ grep 'warning:' build.log
/var/tmp/portage/sys-devel/llvm-13.0.0/work/llvm/utils/unittest/googletest/include/gtest/gtest.h:1527:11: warning: comparison of integers of different signs: 'const int' and 'const unsigned int' [-Wsign-compare]
/var/tmp/portage/sys-devel/llvm-13.0.0/work/llvm-13.0.0_build-abi_x86_32.x86/bin/lli: warning: remote mcjit does not support lazy compilation
/var/tmp/portage/sys-devel/llvm-13.0.0/work/llvm-13.0.0_build-abi_x86_32.x86/bin/lli: warning: remote mcjit does not support lazy compilation
The failed tests from build.log:
Failed Tests (7):
LLVM :: ExecutionEngine/MCJIT/eh.ll
LLVM :: ExecutionEngine/MCJIT/multi-module-eh-a.ll
LLVM :: ExecutionEngine/MCJIT/remote/eh.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-common-symbols-remote.ll
LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_i386.s
LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_x86_64.s
LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s
Testing Time: 182.65s
Skipped : 35
Unsupported : 16291
Passed : 28437
Expectedly Failed: 76
Failed : 7
-fno-semantic-interposition: https://reviews.llvm.org/D102453 and the relevant commit. (Note that in the configured flags above, the build system added fno-semantic-interposition due to my compiler meeting the conditions)
-fno-plt: https://bugs.llvm.org/show_bug.cgi?id=39252#c11
-flto: I haven't looked into this one, probably a GCC specific issue.
Regarding -fno-sematic-interposition: while it is actually default behavior for Clang, there has been a change implemented in Clang 13: https://reviews.llvm.org/D102583
It looks like it is beneficial for compatibility with GCC and is not beneficial towards performance, but I may be wrong. If someone can enlighten me I'd be grateful.