[libcxx-commits] [PATCH] D91379: [libc++] Factor out common logic for calling aligned allocation
Martin Storsjö via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Wed Dec 2 01:06:11 PST 2020
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.
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the libcxx-commits