<atomic>: atomic waits do not link in ARM64

[sylveon]

Describe the bug
When building a program using atomic waits (directly or indirectly through std::counting_semaphore) for ARM64, linking will fail.

Command-line test case

C:\Temp>vsdevcmd -arch=arm64 -host_arch=amd64

C:\Temp>type repro.cpp
#include <atomic>

int main()
{
	std::atomic<int> test(1);
	test.wait(1);
	test.notify_all();
	test.notify_one();
	return test.load();
}

C:\Temp>cl /MDd /std:c++latest repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29515.1 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

/std:c++latest is provided as a preview of language features from the latest C++
working draft, and we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support, and subject
to changes or removal as the working draft evolves. See
https://go.microsoft.com/fwlink/?linkid=2045807 for details.

repro.cpp
Microsoft (R) Incremental Linker Version 14.28.29515.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj
repro.obj : error LNK2019: unresolved external symbol __std_atomic_wait_direct referenced in function "void __cdecl std::_Atomic_wait_direct<int,long>(struct std::_Atomic_storage<int,4> const * const,long,enum std::memory_order)" (??$_Atomic_wait_direct@HJ@std@@YAXQEBU?$_Atomic_storage@H$03@0@JW4memory_order@0@@Z)
repro.obj : error LNK2019: unresolved external symbol __std_atomic_notify_one_direct referenced in function "public: void __cdecl std::_Atomic_storage<int,4>::notify_one(void)" (?notify_one@?$_Atomic_storage@H$03@std@@QEAAXXZ)
repro.obj : error LNK2019: unresolved external symbol __std_atomic_notify_all_direct referenced in function "public: void __cdecl std::_Atomic_storage<int,4>::notify_all(void)" (?notify_all@?$_Atomic_storage@H$03@std@@QEAAXXZ)
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.28.29515\lib\ARM64\msvcprtd.lib : warning LNK4272: library machine type 'ARM64EC' conflicts with target machine type 'ARM64'
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.28.29515\lib\ARM64\OLDNAMES.lib : warning LNK4272: library machine type 'ARM64EC' conflicts with target machine type 'ARM64'
repro.exe : fatal error LNK1120: 3 unresolved externals

C:\Temp>cl /std:c++latest repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29515.1 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

/std:c++latest is provided as a preview of language features from the latest C++
working draft, and we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support, and subject
to changes or removal as the working draft evolves. See
https://go.microsoft.com/fwlink/?linkid=2045807 for details.

repro.cpp
Microsoft (R) Incremental Linker Version 14.28.29515.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj
libcpmt.lib(atomic_wait.obj) : error LNK2019: unresolved external symbol WaitOnAddress referenced in function __std_atomic_wait_direct
libcpmt.lib(atomic_wait.obj) : error LNK2019: unresolved external symbol WakeByAddressSingle referenced in function __std_atomic_notify_one_direct
libcpmt.lib(atomic_wait.obj) : error LNK2019: unresolved external symbol WakeByAddressAll referenced in function __std_atomic_notify_all_direct
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.28.29515\lib\ARM64\OLDNAMES.lib : warning LNK4272: library machine type 'ARM64EC' conflicts with target machine type 'ARM64'
repro.exe : fatal error LNK1120: 3 unresolved externals

Expected behavior
I expected this program to build in both command line cases in the repro.

STL version

Microsoft Visual Studio Community 2019 Preview
Version 16.9.0 Preview 1.0

[cbezault]

The first command line you provided only seems to be reproing with the binaries shipped with VS (which are ARM64EC) not the binaries produced by our build-system here on GitHub (which are ARM64). I've reached out to the appropriate team to get them to investigate.

[cbezault]

After speaking with the lead of the ARM64EC team he stated that the plain ARM64 versions of the missing symbols were erroneously excluded from 16.9p1. He also said that the correct symbols will be available in 16.9p3 at the latest.

I'm a little confused by that since when I dumpbin the 16.9p1 ARM64 libs I see:

RELOCATIONS #8
                                                Symbol    Symbol
 Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000004  PAGEBASE_REL21             90000009       171  __os_arm64x_dispatch_icall
 00000008  PAGEOFFSET_12L             F9400129       171  __os_arm64x_dispatch_icall
 0000000C  PAGEBASE_REL21             9000000A        8A  $iexit_thunk$cdecl$i8$i8i8i8i8
 00000010  PAGEOFFSET_12A             9100014A        8A  $iexit_thunk$cdecl$i8$i8i8i8i8
 00000014  PAGEBASE_REL21             9000000B        BD  __std_atomic_wait_direct
 00000018  PAGEOFFSET_12A             9100016B        BD  __std_atomic_wait_direct

SECTION HEADER #9
.debug$S name
       0 physical address
       0 virtual address
      7C size of raw data
   25F5F file pointer to raw data (00025F5F to 00025FDA)
   25FDB file pointer to relocation table
       0 file pointer to line numbers
       2 number of relocations
       0 number of line numbers
42101040 flags
         Initialized Data
         COMDAT (no symbol)
         Discardable
         1 byte align
         Read Only

RAW DATA #9
  00000000: 04 00 00 00 F1 00 00 00 6D 00 00 00 49 00 47 11  ....├▒...m...I.G.
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 28 00 00 00  ............(...
  00000020: 04 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00  ....$...........
  00000030: 00 00 40 5F 5F 73 74 64 5F 61 74 6F 6D 69 63 5F  ..@__std_atomic_
  00000040: 77 61 69 74 5F 64 69 72 65 63 74 24 65 78 69 74  wait_direct$exit
  00000050: 5F 74 68 75 6E 6B 00 1C 00 12 10 10 00 00 00 00  _thunk..........
  00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00000070: 00 00 40 81 00 02 00 4F 11 00 00 00              ..@....O....

So I'll follow up with him.

[cbezault]

The issue uncovered by your first command line will be resolved in 16.9p2 and the issue found in your second command line will be fixed in 16.9p4 (probably) and can be worked around by explicitly linking in synchronization.lib.

[sylveon]

Thanks for the quick fix!

[cbezault]

I don't think we generally keep issues open after having fixed them. The libs required to fix the first command line came out in 16.9p2 and all source changes necessary are completed.