[llvm-bugs] [Bug 49116] New: max_align_t expected by libc++, but missing in Visual Studio 2019's CRT

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Feb 9 09:12:35 PST 2021


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

            Bug ID: 49116
           Summary: max_align_t expected by libc++, but missing in Visual
                    Studio 2019's CRT
           Product: libc++
           Version: 11.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: colin at reactos.org
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

I have built libc++ 11.0.1 using Visual Studio 2019's clang-cl 10.0.0 against
the Microsoft CRT (version 14.28.29333).
When compiling any application that includes libc++'s <cstddef>, I get a build
failure:

cstddef(53,9): error : no member named 'max_align_t' in the global namespace


While it's correct that <cstddef> needs to provide std::max_align_t since
C++11, the corresponding max_align_t that libc++ expects in the global
namespace also requires C11 support.
However, Visual Studio and its CRT lack full C11 support.

Visual Studio's STL works around this by defining std::max_align_t to double in
its <cstddef> instead of importing it from the global namespace.
Visual Studio's <stddef.h> lacks any mentioning of max_align_t.


For the moment, I can work around this by adding 'using max_align_t = double;'
to libc++'s <cstddef>. Considering that Clang is now officially supported by
Visual Studio, this needs a proper fix though.
Alternatively, you can officially declare that C++11 support requires C11
support and leave it to Microsoft to add the missing C11 support to Visual
Studio ;)


Note that this is no duplicate of bug #20196, which describes a similar issue
with an old non-C11-compliant Clang and a C11-relying GNU libstdc++.

-- 
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/20210209/4dbc4b75/attachment-0001.html>


More information about the llvm-bugs mailing list