From f8f44322314a878d47a27b44645073a3bbd6b110 Mon Sep 17 00:00:00 2001 From: Ella Hathaway Date: Mon, 1 Dec 2025 17:28:35 +0000 Subject: [PATCH] Patch CoreCLR failure fix --- ...ing-Add-flags-when-the-clang-s-major.patch | 118 ++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 src/SourceBuild/patches/runtime/0001-release-8.0-staging-Add-flags-when-the-clang-s-major.patch diff --git a/src/SourceBuild/patches/runtime/0001-release-8.0-staging-Add-flags-when-the-clang-s-major.patch b/src/SourceBuild/patches/runtime/0001-release-8.0-staging-Add-flags-when-the-clang-s-major.patch new file mode 100644 index 000000000000..2fa411310a33 --- /dev/null +++ b/src/SourceBuild/patches/runtime/0001-release-8.0-staging-Add-flags-when-the-clang-s-major.patch @@ -0,0 +1,118 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Aaron R Robinson +Date: Fri, 14 Nov 2025 11:01:41 -0800 +Subject: [PATCH] [release/8.0-staging] Add flags when the clang's major + version is > 20.0 (#121150) +Backport: https://github.com/dotnet/runtime/pull/121150 + +## Customer Impact + +- [x] Customer reported +- [ ] Found internally + +These issues were reported in +https://github.com/dotnet/runtime/issues/119706 as problems with +clang-21 on Fedora 43. The investigation uncovered that clang introduced +a potentially breaking change in clang-20 that we do not currently +consume. These build changes impact VMR related builds when linux +distrobutions performing source build adopt clang-21. + +clang-20 breaking change log - +https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes. + +This PR contains the minimal changes needed to fix issues from the +following PR https://github.com/dotnet/runtime/pull/120775. + +.NET 10: https://github.com/dotnet/runtime/pull/121124 +.NET 9: https://github.com/dotnet/runtime/pull/121151 + +## Regression + +- [ ] Yes +- [x] No + +Build with the new clang-21 compiler will cause the runtime to crash. + +## Testing + +This has been validated using various legs and examples to demonstrate +the usage of undefined behavior these flags convert into "defined" +behavior in C/C++. + +## Risk + +Low. This has zero impact on our production build since we specifically +target clang-16. This is only valid for those partners that are using +clang-20+. +--- + eng/native/configurecompiler.cmake | 18 +++++++++++++++--- + src/coreclr/debug/di/rspriv.h | 4 ++-- + src/coreclr/debug/di/rsthread.cpp | 4 ++-- + 3 files changed, 19 insertions(+), 7 deletions(-) + +diff --git a/eng/native/configurecompiler.cmake b/eng/native/configurecompiler.cmake +index 9a8f16fb457..5da65d586f8 100644 +--- a/eng/native/configurecompiler.cmake ++++ b/eng/native/configurecompiler.cmake +@@ -500,9 +500,21 @@ if (CLR_CMAKE_HOST_UNIX) + #-fms-compatibility Enable full Microsoft Visual C++ compatibility + #-fms-extensions Accept some non-standard constructs supported by the Microsoft compiler + +- # Make signed arithmetic overflow of addition, subtraction, and multiplication wrap around +- # using twos-complement representation (this is normally undefined according to the C++ spec). +- add_compile_options(-fwrapv) ++ if((CMAKE_C_COMPILER_ID STREQUAL "Clang" AND CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 20.0) OR ++ (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 20.0)) ++ # Make signed overflow well-defined. Implies the following flags in clang-20 and above. ++ # -fwrapv - Make signed arithmetic overflow of addition, subtraction, and multiplication wrap around ++ # using twos-complement representation (this is normally undefined according to the C++ spec). ++ # -fwrapv-pointer - The same as -fwrapv but for pointers. ++ add_compile_options(-fno-strict-overflow) ++ ++ # Suppress C++ strict aliasing rules. This matches our use of MSVC. ++ add_compile_options(-fno-strict-aliasing) ++ else() ++ # Make signed arithmetic overflow of addition, subtraction, and multiplication wrap around ++ # using twos-complement representation (this is normally undefined according to the C++ spec). ++ add_compile_options(-fwrapv) ++ endif() + + if(CLR_CMAKE_HOST_APPLE) + # Clang will by default emit objc_msgSend stubs in Xcode 14, which ld from earlier Xcodes doesn't understand. +diff --git a/src/coreclr/debug/di/rspriv.h b/src/coreclr/debug/di/rspriv.h +index 4f55cea3ee3..dca8726db8b 100644 +--- a/src/coreclr/debug/di/rspriv.h ++++ b/src/coreclr/debug/di/rspriv.h +@@ -6354,8 +6354,8 @@ private: + // Lazily initialized. + EXCEPTION_RECORD * m_pExceptionRecord; + +- static const CorDebugUserState kInvalidUserState = CorDebugUserState(-1); +- CorDebugUserState m_userState; // This is the current state of the ++ static const int kInvalidUserState = -1; ++ int m_userState; // This is the current state of the + // thread, at the time that the + // left side synchronized + +diff --git a/src/coreclr/debug/di/rsthread.cpp b/src/coreclr/debug/di/rsthread.cpp +index 4cc38723591..c23875b8e01 100644 +--- a/src/coreclr/debug/di/rsthread.cpp ++++ b/src/coreclr/debug/di/rsthread.cpp +@@ -783,7 +783,7 @@ CorDebugUserState CordbThread::GetUserState() + m_userState = pDAC->GetUserState(m_vmThreadToken); + } + +- return m_userState; ++ return (CorDebugUserState)m_userState; + } + + +@@ -887,7 +887,7 @@ HRESULT CordbThread::CreateStepper(ICorDebugStepper ** ppStepper) + //Returns true if current user state of a thread is USER_WAIT_SLEEP_JOIN + bool CordbThread::IsThreadWaitingOrSleeping() + { +- CorDebugUserState userState = m_userState; ++ int userState = m_userState; + if (userState == kInvalidUserState) + { + //If m_userState is not ready, we'll read from DAC only part of it which