The problem was noticed by the Chrome OS toolchain folks
(crbug.com/1048445) because llvm-objcopy --add-gnu-debuglink would
insert the wrong checksum when processing a binary clarger than 4 GB.
That use case regressed in 1e1e3ba2526 when we started using
llvm::crc32() in more places.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
I was curious if it would be possible to enable the warning for this:
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake b/llvm/cmake/modules/HandleLLVMOptions.cmake index cd48f93f80c..5ec735d9c63 100644 --- a/llvm/cmake/modules/HandleLLVMOptions.cmake +++ b/llvm/cmake/modules/HandleLLVMOptions.cmake @@ -663,6 +663,9 @@ if (LLVM_ENABLE_WARNINGS AND (LLVM_COMPILER_IS_GCC_COMPATIBLE OR CLANG_CL)) # Enable -Wstring-conversion to catch misuse of string literals. add_flag_if_supported("-Wstring-conversion" STRING_CONVERSION_FLAG) + + # Enable -Wshorten-64-to-32. + add_flag_if_supported("-Wshorten-64-to-32" SHORTEN_64_TO_32) endif (LLVM_ENABLE_WARNINGS AND (LLVM_COMPILER_IS_GCC_COMPATIBLE OR CLANG_CL)) if (LLVM_COMPILER_IS_GCC_COMPATIBLE AND NOT LLVM_ENABLE_WARNINGS)
but sadly it seems LLVM relies on these conversions a lot.
Comment Actions
Definitely! (I assume you mean 10.0) Cherry-picked as d0104a596199a41963dbba70338d9ff3c36b185a