[llvm-dev] `_m_prefetchw` type signature mismatch on Windows
Eli Friedman via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 12 11:56:58 PDT 2020
If it's in the Windows SDK headers, it's something we want to address, yes. See https://reviews.llvm.org/D24330 . (I guess the set of intrinsics used by winnt.h changed since the last time someone looked.)
-Eli
> -----Original Message-----
> From: Rickard Andersson <gonz at severnatazvezda.com>
> Sent: Thursday, June 11, 2020 2:30 PM
> To: Eli Friedman <efriedma at quicinc.com>; llvm-dev at lists.llvm.org
> Subject: [EXT] Re[2]: [llvm-dev] `_m_prefetchw` type signature mismatch on
> Windows
>
> Hi again,
>
> It turns out I was mistaken about the source of the error. I've made a
> paste with the error I'm running into instead; it comes from a
> redeclaration (still in a Windows header, but in one of the Windows
> Kits):
>
> https://bpa.st/5PSA
>
> `sqlite3.c` includes `windows.h` and it seems that perhaps there is an
> IFDEF lacking somewhere that causes `winnt.h` to redeclare
> `_m_prefetchw`.
>
> Is it in the scope of clang/LLVM to address this?
>
> // Rickard
>
> ------ Original Message ------
> From: "Eli Friedman" <efriedma at quicinc.com>
> To: "Rickard Andersson" <gonz at severnatazvezda.com>;
> "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Sent: 2020-06-11 21:49:20
> Subject: RE: [llvm-dev] `_m_prefetchw` type signature mismatch on
> Windows
>
> >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