www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Missing builtins MSVC

reply Danny Arends <Danny.Arends gmail.com> writes:
Hey All,

Was trying to use importC with the latest MSVC runtime (Visual 
Studio/Build tools 2026), and got the following linker issues 
(all related to ucrt\wchar.h and ucrt\string.h). Missing from 
`Windows Kits\10\Include\10.0.26100.0`:

Error: undefined reference to `_mm_cvtsi32_si128` referenced from 
`wmemchr`
Error: undefined reference to `_mm256_broadcastw_epi16` 
referenced from `wmemchr`
Error: undefined reference to `_mm256_loadu_si256` referenced 
from `wmemchr`
Error: undefined reference to `_mm256_cmpeq_epi16` referenced 
from `wmemchr`
Error: undefined reference to `_mm256_movemask_epi8` referenced 
from `wmemchr`
Error: undefined reference to `_BitScanForward` referenced from 
`wmemchr`
Error: undefined reference to `_mm_set1_epi16` referenced from 
`wmemchr`
Error: undefined reference to `_mm_loadu_si128` referenced from 
`wmemchr`
Error: undefined reference to `_mm_cmpeq_epi16` referenced from 
`wmemchr`
Error: undefined reference to `_mm_movemask_epi8` referenced from 
`wmemchr`
Error: undefined reference to `_mm_loadl_epi64` referenced from 
`wmemchr`
Error: undefined reference to `_BitScanForward64` referenced from 
`wmemcmp`

I can see from DRuntime that `_BitScanForward` and 
`_BitScanForward64` forward were already added since DMD v2.113.0 
was released.

Also, MSVC toolset 2026 defines `__check_arch_support`, whose 
body references the compiler-emitted constants `__arch_avx10ver` 
and `__arch_inverted`. MSVC codegen stamps these per object from 
its flags, but ImportC does not emit them, so they are unresolved 
even on an older SDK.


Will the _mm* functions be added to __builtins_msvc.d at some 
point ?
Sep 05
parent reply Harry Gillanders <contact harrygillanders.com> writes:
On Saturday, 5 September 2026 at 14:20:08 UTC, Danny Arends wrote:

 Hey All,

 Was trying to use importC with the latest MSVC runtime (Visual 
 Studio/Build tools 2026), and got the following linker issues 
 (all related to ucrt\wchar.h and ucrt\string.h). Missing from 
 `Windows Kits\10\Include\10.0.26100.0`:

 Error: undefined reference to `_mm_cvtsi32_si128` referenced 
 from `wmemchr`
 Error: undefined reference to `_mm256_broadcastw_epi16` 
 referenced from `wmemchr`
 Error: undefined reference to `_mm256_loadu_si256` referenced 
 from `wmemchr`
 Error: undefined reference to `_mm256_cmpeq_epi16` referenced 
 from `wmemchr`
 Error: undefined reference to `_mm256_movemask_epi8` referenced 
 from `wmemchr`
 Error: undefined reference to `_BitScanForward` referenced from 
 `wmemchr`
 Error: undefined reference to `_mm_set1_epi16` referenced from 
 `wmemchr`
 Error: undefined reference to `_mm_loadu_si128` referenced from 
 `wmemchr`
 Error: undefined reference to `_mm_cmpeq_epi16` referenced from 
 `wmemchr`
 Error: undefined reference to `_mm_movemask_epi8` referenced 
 from `wmemchr`
 Error: undefined reference to `_mm_loadl_epi64` referenced from 
 `wmemchr`
 Error: undefined reference to `_BitScanForward64` referenced 
 from `wmemcmp`

 I can see from DRuntime that `_BitScanForward` and 
 `_BitScanForward64` forward were already added since DMD 
 v2.113.0 was released.

 Also, MSVC toolset 2026 defines `__check_arch_support`, whose 
 body references the compiler-emitted constants 
 `__arch_avx10ver` and `__arch_inverted`. MSVC codegen stamps 
 these per object from its flags, but ImportC does not emit 
 them, so they are unresolved even on an older SDK.


 Will the _mm* functions be added to __builtins_msvc.d at some 
 point ?


As you noted, the `_BitScan` intrinsics are implemented in DMD 
nightly, and will be released alongside D v2.114.

The \_mm intrinsics are x86/Intel SIMD intrinsics, and given the 
state of `core.simd` I consider it unlikely that D proper will 
ever support those intrinsics—never mind ImportC!

I haven't tried this myself, but it may be possible to use 
Guillaume Piolat's (excellent) 
[intel-intrinsics](https://code.dlang.org/packages/intel-intrinsics) library to
make those intrinsics available to ImportC by `__import`ing the `inteli` module.

Ideally, something like this:
```
#include <importc_msvc_builtins.h>
__import inteli;
#include <ucrt/wchar.h>
```
would work, but I don't know how D/intel-intrinsics' vector types 
interact with C's vector types.


I haven't looked into the arch detection/querying symbols too 
deeply: but it shouldn't be terribly difficult to define those ad 
hoc before including any headers that use them, as an interim 
solution.
Sep 05
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Saturday, 5 September 2026 at 16:20:32 UTC, Harry Gillanders 
wrote:

 Ideally, something like this:
 ```
 #include <importc_msvc_builtins.h>
 __import inteli;
 #include <ucrt/wchar.h>
 ```
 would work, but I don't know how D/intel-intrinsics' vector 
 types interact with C's vector types.


Good question. The _mm_xxx functions in intel-intrinsics are 
regular D functions though, no C linkage. Some are 
pragma(inline), so I have no idea how that would work in ImportC.

My advice is to translate by hand, depend on intel-intrinsics, 
and enjoy your portable SIMD instead of arch-specific.
Sep 06
parent Guillaume Piolat <first.name gmail.com> writes:
On Sunday, 6 September 2026 at 10:37:47 UTC, Guillaume Piolat 
wrote:

 My advice is to translate by hand, depend on intel-intrinsics, 
 and enjoy your portable SIMD instead of arch-specific.


Besides, it simply can't work inside ImportC.

There are some functions that are macos in C/C++ and have to be 
templates in intel-intrinsics.

One of those is e.g. _mm_shuffle_epi32


In C: `_mm_shuffle_epi32(__m128i a, int imm8);`

However C compilers will ensure that `imm8` is known at 
compile-time, it can be a runtime value.

The only way to translate it in D is as a template:
`_mm_shuffle_epi32(int imm8)(__m128i a);`

There are dozens of such functions where a direct translation 
doesn't work, that have to be templates.
Sep 06