llvm dev - Jun 2020 - `_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

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