[llvm-bugs] [Bug 39435] New: Link error with aligned_allocation on macOS <= 10.13, C++03

[via llvm-bugs]

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

            Bug ID: 39435
           Summary: Link error with aligned_allocation on macOS <= 10.13,
                    C++03
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ldionne at apple.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

The following program produces a link error:

// t.cpp
#include <memory>
int main() { std::get_temporary_buffer<int>(10); }

When compiled like this on macOS 10.13 or older:

$ clang++ -x c++ -c t.cpp -mmacosx-version-min=10.13 -std=c++03 -nostdinc++ -I
libcxx/include -isysroot $(xcrun --sdk macosx10.13 --show-sdk-path) -o t.o
$ clang++ -o t.exe t.o -mmacosx-version-min=10.13 -L
<path-to-10.13-libc++-dylib> -Wl,-rpath,<path-to-10.13-libc++-dylib>
-nodefaultlibs -lc++ -lSystem

The result is:

Undefined symbols for architecture x86_64:
  "operator new(unsigned long, std::align_val_t, std::nothrow_t const&)",
referenced from:
      std::__1::pair<int*, long> std::__1::get_temporary_buffer<int>(long) in
t.o
ld: symbol(s) not found for architecture x86_64


This has been bisected to be caused by 1d97e2ba2 (in the monorepo), aka r344207
in SVN:

--------------------------------------------------------------------------------
r344207 | ericwf | 2018-10-10 20:17:24 -0400 (Wed, 10 Oct 2018) | 17 lines

Distinguish between library and language support for aligned allocation.

There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.

There are times where libc++ needs to distinguish between the two.

This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.

Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.
--------------------------------------------------------------------------------

-- 
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/20181025/a68dedec/attachment.html>