dlang
ImportC: _InterlockedExchangeAdd and a ton of other VC intrinsics are not recognized
Max Samukha (@maxsamukha) reported this on 2023-05-05T19:58:20Z
Transferred from https://issues.dlang.org/show_bug.cgi?id=23894
CC List
- Walter Bright (@WalterBright)
- Carl Sturtivant
Description
"Windows.h" intrinsics:
main.obj : error LNK2019: unresolved external symbol _InterlockedExchangeAdd referenced in function _InlineInterlockedAdd
main.obj : error LNK2019: unresolved external symbol _InterlockedExchangeAdd64 referenced in function _InlineInterlockedAdd64
main.obj : error LNK2019: unresolved external symbol _mul128 referenced in function MultiplyExtract128
main.obj : error LNK2019: unresolved external symbol __shiftright128 referenced in function MultiplyExtract128
main.obj : error LNK2019: unresolved external symbol _umul128 referenced in function UnsignedMultiplyExtract128
main.obj : error LNK2019: unresolved external symbol _ReadWriteBarrier referenced in function BarrierAfterRead
main.obj : error LNK2019: unresolved external symbol __stosb referenced in function RtlSecureZeroMemory
main.obj : error LNK2019: unresolved external symbol __readgsqword referenced in function NtCurrentTeb
Fun!
!!!There are attachements in the bugzilla issue that have not been copied over!!!
bugzilla (@WalterBright) commented on 2023-05-11T06:01:59Z
ImportC doesn't support gcc's inline assembler, either. Is the use of these intrinsics blockable with some macro?
maxsamukha commented on 2023-05-11T17:12:13Z
(In reply to Walter Bright from comment #1)
> Is the use of these intrinsics blockable with some macro?
I don't think so. They are not conditioned on a macro that could be simply (un)defined (if that's what you meant).
bugzilla (@WalterBright) commented on 2023-05-29T07:10:30Z
Could you please post the section of code in the windows.h you have?
maxsamukha commented on 2023-06-03T06:53:11Z
Created attachment 1878
VC intrinsics referenced by windows.h
maxsamukha commented on 2023-06-03T06:53:58Z
(In reply to Walter Bright from comment #3)
> Could you please post the section of code in the windows.h you have?
Please see an isolated test case in the attachment.
dfj1esp02 commented on 2023-12-01T10:26:40Z
Another problem is
#define GENERIC_READ (0x80000000L)
these are interpreted as helper macros due to parentheses and skipped.
bugzilla (@WalterBright) commented on 2023-12-02T02:27:35Z
(In reply to anonymous4 from comment #6)
> Another problem is
>
> #define GENERIC_READ (0x80000000L)
>
> these are interpreted as helper macros due to parentheses and skipped.
This PR should resolve that problem.
https://github.com/dlang/dmd/pull/15871
sturtivant commented on 2024-03-11T05:49:19Z
Here's a workaround.
https://forum.dlang.org/post/[email protected]
There's a list of all x64 MSVC intrinsics at the included link with prototypes with named parameters.
I think I have a solution for the linker errors. The link error happens in functions marked __forceinline. We shouldn’t even be generating code for them unless they are used and so we shouldn’t be failing to link. ImportC is interpreting them as regular old functions with extern visibility.
