mozjs115: builds fail for macOS 10.15 [using clang-16]: error: no member named 'aligned_alloc' in the global namespace

[mascguy (Christopher Nielsen)]

Could use some help with this one, since aligned_alloc should be available for 10.14+ ...?

Note that the failure occurs both on our 10.15 buildbot, as well as locally.

​https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/178414/steps/install-port/logs/stdio

/opt/local/bin/clang++-mp-16 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.15
-stdlib=libc++ -o putil.o -c  -fvisibility=hidden -fvisibility-inlines-hidden -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-fstack-protector-strong -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1
-DU_HIDE_OBSOLETE_UTF_OLD_H=1 -DUCONFIG_NO_LEGACY_CONVERSION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS
-DU_CHARSET_IS_UTF8 -DUNISTR_FROM_CHAR_EXPLICIT=explicit -DUNISTR_FROM_STRING_EXPLICIT=explicit -DU_ENABLE_DYLOAD=0
-I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/config/external/icu/common
-I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/js/src/obj/config/external/icu/common
-I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/intl/icu/source/i18n
-I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/js/src/obj/dist/include
-DMOZILLA_CLIENT
-include /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/js/src/obj/js/src/js-confdefs.h
-I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -fno-sized-deallocation -fno-aligned-new -pipe -Os
-stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -fPIC -fno-rtti -ffunction-sections
-fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -gdwarf-4 -O3 -fno-omit-frame-pointer -funwind-tables -Wall
-Wbitfield-enum-conversion -Wdeprecated-this-capture -Wempty-body -Wformat-type-confusion -Wignored-qualifiers -Wpointer-arith
-Wshadow-field-in-constructor-modified -Wsign-compare -Wtautological-constant-in-range-compare -Wtype-limits
-Wno-error=tautological-type-limit-compare -Wunreachable-code -Wunreachable-code-return -Wunused-but-set-parameter -Wno-invalid-offsetof
-Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis
-Wc++2a-compat -Wenum-compare-conditional -Wenum-float-conversion -Wno-error=deprecated -Wno-error=deprecated-anon-enum-enum-conversion
-Wno-error=deprecated-enum-enum-conversion -Wno-error=deprecated-pragma -Wno-error=deprecated-this-capture -Wcomma -Wimplicit-fallthrough
-Wduplicate-method-arg -Wduplicate-method-match -Wmissing-method-return-type -Wobjc-signed-char-bool -Wsemicolon-before-method-body
-Wsuper-class-method-mismatch -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wno-error=atomic-alignment -Wno-error=deprecated-builtins -Wformat -Wformat-security -Wno-psabi
-Wthread-safety -Werror=unguarded-availability-new -Wno-error=builtin-macro-redefined -Wno-unknown-warning-option -frtti -Wno-c++20-compat
-Wno-comma -Wno-implicit-const-int-float-conversion -Wno-macro-redefined -Wno-microsoft-include -Wno-tautological-unsigned-enum-zero-compare
-Wno-unreachable-code-loop-increment -Wno-unreachable-code-return -fno-strict-aliasing -ffp-contract=off  -MD -MP -MF
.deps/putil.o.pp
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/intl/icu/source/common/putil.cpp

In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/intl/icu/source/common/putil.cpp:68:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_mozjs115/mozjs115/work/mozjs-115.2.0/intl/icu/source/common/umutex.h:25:
In file included from /opt/local/libexec/llvm-16/bin/../include/c++/v1/condition_variable:111:
In file included from /opt/local/libexec/llvm-16/bin/../include/c++/v1/__memory/shared_ptr.h:22:
In file included from /opt/local/libexec/llvm-16/bin/../include/c++/v1/__memory/allocation_guard.h:14:
In file included from /opt/local/libexec/llvm-16/bin/../include/c++/v1/__memory/allocator_traits.h:14:
In file included from /opt/local/libexec/llvm-16/bin/../include/c++/v1/__memory/construct_at.h:23:
/opt/local/libexec/llvm-16/bin/../include/c++/v1/new:355:14: error: no member named 'aligned_alloc' in the global namespace
    return ::aligned_alloc(__alignment, __size > __rounded_size ? __size : __rounded_size);
           ~~^

[jmroot (Joshua Root)]

C++17 provides std::aligned_alloc but not necessarily aligned_alloc in the global namespace.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

C++17 provides std::aligned_alloc but not necessarily aligned_alloc in the global namespace.

The perplexing part of this, is that ::aligned_alloc is being referenced from LLVM-16 header new.

Here's the relevant section from file: /opt/local/libexec/llvm-16/include/c++/v1/new:

#if !defined(_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION)
// Low-level helpers to call the aligned allocation and deallocation functions
// on the target platform. This is used to implement libc++'s own memory
// allocation routines -- if you need to allocate memory inside the library,
// chances are that you want to use `__libcpp_allocate` instead.
//
// Returns the allocated memory, or `nullptr` on failure.
inline _LIBCPP_INLINE_VISIBILITY void* __libcpp_aligned_alloc(std::size_t __alignment, std::size_t __size) {
#  if defined(_LIBCPP_MSVCRT_LIKE)
    return ::_aligned_malloc(__size, __alignment);
#  elif _LIBCPP_STD_VER > 14 && !defined(_LIBCPP_HAS_NO_C11_ALIGNED_ALLOC)
    // aligned_alloc() requires that __size is a multiple of __alignment,
    // but for C++ [new.delete.general], only states "if the value of an
    // alignment argument passed to any of these functions is not a valid
    // alignment value, the behavior is undefined".
    // To handle calls such as ::operator new(1, std::align_val_t(128)), we
    // round __size up to the next multiple of __alignment.
    size_t __rounded_size = (__size + __alignment - 1) & ~(__alignment - 1);
    // Rounding up could have wrapped around to zero, so we have to add another
    // max() ternary to the actual call site to avoid succeeded in that case.
    return ::aligned_alloc(__alignment, __size > __rounded_size ? __size : __rounded_size);
#  else
    void* __result = nullptr;
    (void)::posix_memalign(&__result, __alignment, __size);
    // If posix_memalign fails, __result is unmodified so we still return `nullptr`.
    return __result;
#  endif
}

One workaround might be to define _LIBCPP_HAS_NO_C11_ALIGNED_ALLOC, to force use of posix_memalign. But should that be necessary?

Or do we need to ensure there's an include for header stdlib.h (or cstdlib) prior? Which also seems odd, given that this is an LLVM header...

[kencu (Ken)]

NB:

​https://github.com/llvm/llvm-project/blob/a9d4ddd98a0bc495126027122fdca751b6841ceb/libcxx/include/__config#L934

[kencu (Ken)]

A small test file running on 10.15 should help sort out what is going on.

​https://github.com/llvm/llvm-project/commit/eb6fbad711a2cd39ccfb4b111db0a77933e06573

​https://reviews.llvm.org/D138196

it could be there is an error in thinking 10.15 supports aligned_alloc() which I presume comes from the system.