[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
Mon Dec 7 04:29:05 PST 2020

mstorsjo added a comment.

In D91379#2433128 <https://reviews.llvm.org/D91379#2433128>, @mstorsjo wrote:

> In D91379#2429302 <https://reviews.llvm.org/D91379#2429302>, @mstorsjo wrote:
>> In D91379#2428659 <https://reviews.llvm.org/D91379#2428659>, @dmajor wrote:
>>> In D91379#2427960 <https://reviews.llvm.org/D91379#2427960>, @mstorsjo wrote:
>>>> I haven't run into this issue - how do you end up getting intrin.h included before the other includes here?
>>> Any case with intrin.h coming first should do it:
>>>   $ cat test.cpp
>>>   #include <intrin.h>
>>>   #include <new>
>>>   $ ./clang/bin/x86_64-w64-mingw32-clang++ -c test.cpp 
>>>   In file included from test.cpp:2:
>>>   /home/vm/Desktop/mingwtest/clang/bin/../x86_64-w64-mingw32/include/c++/v1/new:314:12: error: no member named '_aligned_malloc' in the global namespace
>>>     return ::_aligned_malloc(__size, __alignment);
>>>            ~~^
>>>   /home/vm/Desktop/mingwtest/clang/bin/../x86_64-w64-mingw32/include/c++/v1/new:326:5: error: no type named '_aligned_free' in the global namespace
>>>     ::_aligned_free(__ptr);
>>>     ~~^
>>>   2 errors generated.
>> Ah, doh. Indeed, I can reproduce that. Apparently the code I build regularly doesn't happen to use that setup.
>> I'll look into fixing the mingw-w64 header bug.
> See https://sourceforge.net/p/mingw-w64/mailman/message/37168701/ and https://sourceforge.net/p/mingw-w64/mailman/message/37168702/ for patches that should fix this. It turned out to be less obvious and a bit more convolved than it first seemed.

A fix for this is pushed now in https://sourceforge.net/p/mingw-w64/mingw-w64/ci/660e09f3cb20f181b6d6435cb623d65a3922a063/.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list