[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