在 2025-9-24 21:55, Pali Rohár 写道:
Without including windows.h it is possible to do declare InterlockedExchange and call it. See: https://godbolt.org/z/78qKcMKoxlong __stdcall InterlockedExchange(volatile long*, long); long test(volatile long* arg1, long arg2) { return InterlockedExchange(arg1, arg2); } And it is possible also with windows.h by undefining macro InterlockedExchange. See: https://godbolt.org/z/bKboTEoYT #include <windows.h> #undef InterlockedExchange LONG WINAPI InterlockedExchange(volatile LONG*, LONG); LONG test(volatile LONG* arg1, LONG arg2) { return InterlockedExchange(arg1, arg2); }
No, don't do that. It will cause a linker error on x86-64 and ARM targets.
In addition, is there a reason to re-implement them, instead of removing `DATA` from the DEF?Well, I do not know. I saw that all intrinsics are defined in source code instead of redirection to kernel32.dll implementation. So choose same strategy, define in in the mingw-w64 source code. I can imagine that LTO compilations (now or in future) could be able to inline this call, but that is just a speculation. Maybe one thing, which could be interested: API of InterlockedIncrement and InterlockedDecrement in kernel32.dll was changed in past, previously in past it returned only sign of the original value, now it returns the full original value.
Those should be intrinsics and should never be imported, like GCC MMX/SSE/AVX intrinsics which are defined as `extern inline` with `gnu_inline` and `always_inline` but no external definitions actually exist.
-- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
