Add flags for overflow on clang.#120775
Conversation
In clang-20 there is a known breaking change to -fwrapv that impacted us. Details can be found at https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes. Add the -fno-strict-aliasing to match our MSVC usage as well.
|
/cc @rnkovacs |
|
Tagging subscribers to this area: @mangod9 |
jkoritzinsky
left a comment
There was a problem hiding this comment.
One of these days I'll get UBSAN working..
|
We should have a build image with clang 21 now: dotnet/dotnet-buildtools-prereqs-docker#1516 You can try updating all |
|
Last CI run still used clang 20: New images were built a few hours ago dotnet/dotnet-buildtools-prereqs-docker#1516 (comment) (it doesn't automatically rebuild the subtree). |
|
@jkotas, looks like we need to apply: --- a/src/native/libs/System.Security.Cryptography.Native/pal_x509.c
+++ b/src/native/libs/System.Security.Cryptography.Native/pal_x509.c
@@ -1250,6 +1250,7 @@ static int32_t X509ChainVerifyOcsp(X509_STORE_CTX* storeCtx, X509* subject, X509
{
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wcast-qual"
+#pragma clang diagnostic ignored "-Wimplicit-void-ptr-cast"
if (i2d_OCSP_RESPONSE_bio(bio, resp))
#pragma clang diagnostic pop
{ |
|
FreeBSD build fix: --- a/src/native/libs/System.Native/pal_interfaceaddresses.c
+++ b/src/native/libs/System.Native/pal_interfaceaddresses.c
@@ -561,7 +561,7 @@ int32_t SystemNative_EnumerateGatewayAddressesForInterface(void* context, uint32
return -1;
}
- uint8_t* buffer = malloc(byteCount);
+ uint8_t* buffer = (uint8_t*)malloc(byteCount);
if (buffer == NULL)
{
errno = ENOMEM;
@@ -587,7 +587,7 @@ int32_t SystemNative_EnumerateGatewayAddressesForInterface(void* context, uint32
byteCount = tmpEstimatedSize;
free(buffer);
- buffer = malloc(byteCount);
+ buffer = (uint8_t*)malloc(byteCount);
if (buffer == NULL)
{
errno = ENOMEM; |
|
It would be nice to update tables in https://github.com/dotnet/runtime/blob/f0db8f9d9668ba03897739152d02623acbd04466/docs/workflow/using-docker.md at the same time (replace |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/ba-g Unrelated failures in outerloop |
|
@AaronRobinsonMSFT perhaps this is needed in some other places too: https://github.com/search?q=repo%3Adotnet%2Fdotnet%20-fwrapv&type=code |
|
Automated code flow will sync with VMR. |
|
@am11 did you click the link? There's some thing for mono, and also in src/deployment-tools and src/diagnostics. |
|
We sync eng/native with dotnet/diagnostics from time to time. I can resync it. Not sure if |
Updated comments and compile options for signed overflow and strict aliasing. See related code for dotnet/runtime - dotnet/runtime#120775
Updated compiler options to improve signed overflow handling and suppress strict aliasing rules. See related code for dotnet/runtime#120775
Updated compiler options to improve signed overflow handling and suppress strict aliasing rules. See related code for dotnet/runtime#120775
Related changes for mono - see #120775
Updated comments and compile options for signed overflow and strict aliasing. See related code for dotnet/runtime - dotnet/runtime#120775
## Customer Impact - [x] Customer reported - [ ] Found internally These issues were reported in #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 PRs #120644 and #120775. ## Regression - [x] Yes - [ ] No Moving to the new clang-21 compiler will cause the runtime to crash. This is a regression from using .NET 10 and the default compiler of clang-19. ## 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 makes clang-21 more permissive and is limited to non official product builds. --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com>
…0.0 (#121151) ## Customer Impact - [x] Customer reported - [ ] Found internally These issues were reported in #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 #120775. .NET 10: #121124 .NET 8: #121150 ## 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-18. This is only valid for those partners that are using clang-20+.
…0.0 (#121150) ## Customer Impact - [x] Customer reported - [ ] Found internally These issues were reported in #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 #120775. .NET 10: #121124 .NET 9: #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+.
In clang-20 there is a known breaking change to
-fwrapvthat impacted us. Details can be found at https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes.Add the
-fno-strict-aliasingto match our MSVC usage as well.Contributes to #119706