On 25 October 2017 at 12:24, Liu Hao wrote:
> On 2017/10/25 18:35, Jonathan Wakely wrote:
>>
>> Is this because -std=c99 sets __STRICT_ANSI__?
>> > The C++ runtime is not built with -std=c99, of course.
>
>
>>
>
>
> No. It will not compile despite the `-std=` option, because
> `_aligned_{malloc,free}` are conditionally `#ifdef`'d out by the following
> code (and that is why I think it is a bug because avoidance of spurious
> `collisions` results in no declarations at all):
>
> ```
> /* Make sure that X86intrin.h doesn't produce here collisions. */
> #if (!defined (_XMMINTRIN_H_INCLUDED) && !defined (_MM_MALLOC_H_INCLUDED))
> || defined(_aligned_malloc)
> #define __DO_ALIGN_DEFINES
> #endif
>
> (... abridged ...)
>
> #ifdef __DO_ALIGN_DEFINES
> _CRTIMP void __cdecl _aligned_free(void *_Memory);
> _CRTIMP void *__cdecl _aligned_malloc(size_t _Size,size_t _Alignment);
> #endif
> ```
>
>> I don't really care whether _aligned_malloc works in arbitrary C
>> programs, what I care about is whether it works in
>> libsupc++/new_opa.cc when _GLIBCXX_HAVE__ALIGNED_MALLOC is defined.
>>
>> I assume new_opa.cc does build for MinGW-w64, but does it build for
>> MinGW? That still seems to be stuck on GCC 4.x
>>
>
> Yeah this reminds me that the bulk of the community is still having problems
> with distinguishing MinGW-w64 from MinGW. Unless the OP clarify which one
> he/she is using exactly, this discussion is much likely going to be
> meaningless. o_O
I was asking David about his previous build failures, where he clearly
said "the 32-bit MinGW" so I assume that's what he meant.
You're the one who added the w64 mailing list when we weren't discussing w64 :-)
