[libcxx-commits] [PATCH] D91379: [libc++] Factor out common logic for calling aligned allocation

[dmajor via Phabricator via libcxx-commits]

dmajor added a subscriber: mstorsjo.
dmajor added a comment.

In D91379#2426975 <https://reviews.llvm.org/D91379#2426975>, @ldionne wrote:

> In D91379#2423372 <https://reviews.llvm.org/D91379#2423372>, @dmajor wrote:
>
>> Our mingw builds are failing with `error: no member named '_aligned_malloc' in the global namespace`. Should the `new` header have an `#include <malloc.h>` somewhere?
>
> That's weird, as we were not including `<malloc.h>` anywhere before either. Can you confirm that including `<malloc.h>` fixes your issue? I'm wary of adding non standard includes in our headers, since it causes all kinds of problems.

That didn't fix our issue. On closer inspection I think this is a weirdness in the mingw headers but I could use a double check: https://github.com/mirror/mingw-w64/search?q=_MM_MALLOC_H_INCLUDED

`_aligned_malloc` can be provided by either `<malloc.h>` or `<stdlib.h>`, as long as you haven't defined `_MM_MALLOC_H_INCLUDED`. Previously, `new.cpp` worked because it included `<stdlib.h>` first thing. Now, in our build, translation units that first include `<intrin.h>` will set `_MM_MALLOC_H_INCLUDED` which prevents anything later from picking up `_aligned_malloc`. Am I interpreting that correctly? This trickery in `<intrin.h>` seems very strange...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91379/new/

https://reviews.llvm.org/D91379