[clang] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h conflicts (PR #115099)

James Y Knight via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 6 08:16:00 PST 2024


jyknight wrote:

So, this is interesting, because the decls _already_ don't conflict, normally. They only conflict if the x86intrin.h is included within a `extern "C++" {}` block, _and_ is included after windows.h.

It comes down to, effectively this. Note, run the examples with `-fms-extensions` (or a windows target), because that suppresses err_static_non_static.
```c++
static void _m_prefetchw() {} // from prfchwintrin.h
extern "C" { void _m_prefetchw(); } // from winnt.h
```

Notably, surrounding the first in extern "C++" still doesn't trigger an error:
```c++
extern "C++" { static void _m_prefetchw() {} }
extern "C" { void _m_prefetchw(); }
```
even though it would've if the declaration didn't say "static":
```c++
extern "C++" { void _m_prefetchw() {} }
extern "C" { void _m_prefetchw(); } // error
```
Which I guess means Clang decides language-linkage doesn't really matter for internal linkage functions? I haven't traced where in the code that happens, but it seems vaguely sensible.

Yet, _reversing_ the order:
```c++
extern "C" { void _m_prefetchw(); }
extern "C++" { static void _m_prefetchw() {} }
```
does throw an "error: declaration of '_m_prefetchw' has a different language linkage" on the second line..

If language-linkage doesn't matter for static functions (seems sensible), I think we probably also shouldn't throw an error for that last case. And, if we did stop throwing that error, the incompatibility here disappears, and this PR is unnecessary.

https://github.com/llvm/llvm-project/pull/115099


More information about the cfe-commits mailing list