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

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added a comment.

In D91379#2427555 <https://reviews.llvm.org/D91379#2427555>, @dmajor wrote:

> 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...

I haven't run into this issue - how do you end up getting intrin.h included before the other includes here?

As for the mingw headers, yeah that aspect with `_mm_malloc` vs `_aligned_malloc` does seem like a bit of a mess - digging through the history finds commits from 2009 and 2010 that touched that, but I can't entirely make out what they attempted to do... I'll see if I can manage to fix that (figure out exactly what it did attempt to do back in 2010, and straighten out a bit of it). Anything relating to intrin.h is a huge mess though, as it is pretty tightly coupled with the compiler and interacts with compiler provided headers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91379