[llvm-dev] `_m_prefetchw` type signature mismatch on Windows

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 11 11:49:20 PDT 2020


If clang is finding MSVC's mm3dnow.h instead of its own, you've misconfigured the include paths.  clang should always use its own version.

-Eli

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Rickard
> Andersson via llvm-dev
> Sent: Thursday, June 11, 2020 6:15 AM
> To: llvm-dev at lists.llvm.org
> Subject: [EXT] [llvm-dev] `_m_prefetchw` type signature mismatch on
> Windows
>
> Hi,
>
> I was compiling `sqlite3.c` via Zig a while ago and noticed a type
> mismatch between the Windows headers and the LLVM headers that Zig
> ships
> with.
>
> The Windows header `mm3dnow.h` declares it as:
>
>      void _m_prefetchw(volatile const void*_Source);
>
> Whereas the LLVM header `clang\lib\Headers\prfchwintrin.h` declares:
>
>      static __inline__ void __attribute__((__always_inline__,
> __nodebug__))
>      _m_prefetchw(volatile const void *__P) {
>        __builtin_prefetch (__P, 1, 3 /* _MM_HINT_T0 */);
>      }
>
> `__builtin_prefetch`, which `_m_prefetchw` is using, is defined as
> taking `const void*` at the moment.
>
> The mismatch effectively causes the function to have two different
> signatures when compiling C source in Zig on Windows. The most direct
> change is to modify the shipped Zig headers, but it'd be interesting to
> see this fixed at the source.
>
> Is there any major issue with `ifdef`ing a solution when using MSVC that
> anyone can see?
>
> With regards,
> Rickard Andersson
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list