[llvm-bugs] [Bug 35356] New: __STDCPP_DEFAULT_ALIGNED_NEW__ on Windows

[via llvm-bugs]

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

            Bug ID: 35356
           Summary: __STDCPP_DEFAULT_ALIGNED_NEW__ on Windows
           Product: clang
           Version: 5.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Casey at Carter.net
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

Clang 5.0.0 -m64 defines __STDCPP_DEFAULT_NEW_ALIGNMENT__ incorrectly when
using the MSVC standard libraries. This will become an interop problem when
Visual Studio 2017 version 15.5 ships since it includes support for overaligned
new: there is potential for ODR violations when clang TUs with
__STDCPP_DEFAULT_NEW_ALIGNMENT__ defined to 8 link with C1XX TUs with
__STDCPP_DEFAULT_NEW_ALIGNMENT__ defined to 16. I've almost finished
implementing <memory_resource> for a future release, and I've observed the
results of said ODR violations first-hand when linking a test compiled with
Clang to the separately-C1XX-compiled bits in the library.

It appears that Clang is always using the value 8 - which happens to be
alignof(max_align_t) for both x86 and x64 flavors of the MSVC STL - instead of
the proper (2 * sizeof(void *)) which is the alignment guaranteed by malloc
(and the default implementation of operator new in vcruntime that simply calls
malloc).

I'm not sure how or if Clang detects that it's using the MSVC STL vs. libc++ on
Windows, and I'm unsure if libc++ on Windows implements operator new other than
by calling malloc in the CRT. It would be a good idea to check with such
stakeholders before simply changing the value of
__STDCPP_DEFAULT_NEW_ALIGNMENT__ out from under them.

-- 
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/20171118/4fac9193/attachment.html>