You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7 libc++ tests and 51 std tests include <Windows.h> (possibly via a centralized header, e.g. test_death.hpp), and produce warning C28301: C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winnt.h(3209) : warning C28301: No annotations for first declaration of '_InterlockedCompareExchange128'. See c:\program files\microsoft visual studio\2022\preview\vc\tools\msvc\14.44.35207\include\intrin0.inl.h(185).
I've suppressed the warning by adding the /wd28301 compiler option. It might also be possible to instead add a pragma to each affected file.
Windows SDK 10.0.22621.0 uses #pragma intrinsic(fabsf) in <corecrt_math.h> for ARM64EC, which seems to cause problems in several tests.
GH_002206_unreserved_names needs to avoid defining intrinsic as a macro.
3 modules tests fail with error LNK2019: unresolved external symbol fabsf referenced in function #fabsf$exit_thunk (EC Symbol).
2 of them pass locally with Windows SDK 10.0.26100.0, but VSO_1775715_user_defined_modules is still failing with tests\std\tests\VSO_1775715_user_defined_modules\user.ixx(24): error C2678: binary '==': no operator found which takes a left-hand operand of type 'const std::string' (or there is no acceptable conversion).
Windows SDK 10.0.26100.0 instead uses #pragma function(fabsf) in <corecrt_math.h>, which seems to fix the abovementioned problems, but breaks Clang 19. This is LLVM-116256 and fixed in Clang 20.
I didn't check whether all tests pass with Clang 19 and Windows SDK 10.0.22621.0.
GH_001103_countl_zero_correctness needs to update its preprocessor condition to exclude ARM64EC. I've copied the condition from <__msvc_bit_utils.hpp>.
The reason will be displayed to describe this comment to others. Learn more.
This error C2678 turns out to be unaffected by architecture or Windows SDK version, and affected by the execution charset: error C2678 manifests if and only if the execution charset is not self-synchronizing (e.g. cp932, cp936). With cp1252 or UTF-8, the test compiles successfully.
No change requested for this PR,but we could maybe file a bug report against the compiler.
ARM64Related to the ARM64 architectureinfrastructureRelated to repository automationtestRelated to test code
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2310
<Windows.h>
(possibly via a centralized header, e.g.test_death.hpp
), and produce warning C28301:C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winnt.h(3209) : warning C28301: No annotations for first declaration of '_InterlockedCompareExchange128'. See c:\program files\microsoft visual studio\2022\preview\vc\tools\msvc\14.44.35207\include\intrin0.inl.h(185).
/wd28301
compiler option. It might also be possible to instead add a pragma to each affected file.#pragma intrinsic(fabsf)
in<corecrt_math.h>
for ARM64EC, which seems to cause problems in several tests.GH_002206_unreserved_names
needs to avoid definingintrinsic
as a macro.error LNK2019: unresolved external symbol fabsf referenced in function #fabsf$exit_thunk (EC Symbol)
.VSO_1775715_user_defined_modules
is still failing withtests\std\tests\VSO_1775715_user_defined_modules\user.ixx(24): error C2678: binary '==': no operator found which takes a left-hand operand of type 'const std::string' (or there is no acceptable conversion)
.#pragma function(fabsf)
in<corecrt_math.h>
, which seems to fix the abovementioned problems, but breaks Clang 19. This is LLVM-116256 and fixed in Clang 20.GH_001103_countl_zero_correctness
needs to update its preprocessor condition to exclude ARM64EC. I've copied the condition from<__msvc_bit_utils.hpp>
.