[llvm-bugs] [Bug 47099] New: Clang-overlay of <intrin.h> breaks <intrin0.h> in VS 2019 version 16.8p1

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47099

            Bug ID: 47099
           Summary: Clang-overlay of <intrin.h> breaks <intrin0.h> in VS
                    2019 version 16.8p1
           Product: clang
           Version: 10.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
          Assignee: unassignedclangbugs at nondot.org
          Reporter: billy.oneal at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Previously reported by a Visual Studio customer as
https://developercommunity.visualstudio.com/content/problem/1144026/visual-studio-version-1680-preview-10-no-longer-co.html

The standard libraries have an `<intrin0.h>` where we declare intrinsics used
by the standard library headers as a throughput optimization, because
`<intrin.h>` is *huge* and causes measurable throughput costs to `#include
<atomic>`.

As part of implementing C++20, we needed new intrinsics for `<bit>` so we moved
them from `<intrin.h>` to `<intrin0.h>`. Unfortunately, that is breaking
whatever overlay mechanism Clang on Windows uses to select its version of
`<intrin.h>` because it tries to declare `_tzcnt_u32` and `_tzcnt_u64` as
object-like macros.

We are interested in investigating a scheme whereby our official `<intrin.h>`
would do `#ifdef __clang__`, then `#include <whatever clang wants.hpp>` or
similar so that we would have a more firmly established contract for clang's
extensions rather than needing overlays and `#include_next`.

Billy ONeal
Visual C++ Libraries

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200810/e9e56018/attachment.html>