-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix build issues with clang18 #94782
Conversation
@dotnet-policy-service agree |
eng/native/configurecompiler.cmake
Outdated
@@ -606,6 +606,10 @@ if (CLR_CMAKE_HOST_UNIX) | |||
# other clang 16.0 suppressions | |||
add_compile_options(-Wno-single-bit-bitfield-constant-conversion) | |||
add_compile_options(-Wno-cast-function-type-strict) | |||
|
|||
# clang 18.0 warns about VLAs being a C++ extension by default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we use VLAs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two instance when building for Linux:
runtime/src/coreclr/gc/unix/gcenv.unix.cpp
Line 635 in 590d664
unsigned long nodeMask[nodeMaskLength]; |
and
runtime/src/coreclr/pal/src/file/path.cpp
Line 402 in 590d664
char TempBuffer[nBufferLength > 0 ? nBufferLength : 1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is just these two, I think it is better to convert them to use alloca.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be easy, I'll change them tomorrow! Should I also check if there are more in code that's only used for different platforms? Also if there are no notes in the coding guidelines it might be worth mentioning that VLAs shouldn't be used (and maybe enable warnings for them?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be easy, I'll change them tomorrow!
Thanks!
Should I also check if there are more in code that's only used for different platforms?
I do not expect that you will find any. VLAs are not supported on Windows that prohibits their use in majority of the code. And there is very little code in the repo that is non-Windows non-Linux.
there are no notes in the coding guidelines it might be worth mentioning that VLAs shouldn't be used (and maybe enable warnings for them
VLAs are very niche. I do not think it is worth mentioning them in the coding guidelines. Enabling the warnings for them on older compilers sounds good if it is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converted them to alloca
and enabled warnings for unix hosts. If I understand it correctly only MSVC is supported for Windows which doesn't support VLAs (for C++), for Linux there is Clang and GCC, both of which support -Wvla
, this should cover every supported compiler/platform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Clang 18 introduced some changes that prevent building CoreCLR:
-Werror
. Enabled -Wvla-extension by default in C++ compilation modes llvm/llvm-project#62836stdarg.h
now has a guard that depends onva_arg
not being defined, currently the PAL internal doesn't undefined that macro (despite PAL defining it) which preventstdarg.h
from being included again and causes missing symbols (va_start
,va_end
,va_arg
).This PR fixes the warning by disabling it to match the behaviour of previous clang versions and undefines
va_arg
inpalinternal.h
.