Windows build failure for gcc7 release candidates on 32-bit MinGW

[Marc Glisse]

On Sun, 30 Apr 2017, David Gressett wrote:

> I'm working on getting the 32-bit MinGW platform on Windows updated
> to a newer gcc than the gcc 5.3.0 thst is provided by the 32-bit  MinGW
> installer Iwas able to build gcc 5.4.0 and 6.3.0 with only minor\difficulties,
> but the 7.0.1 release candidates do not build.
>
> The problem occurs when xgcc attempts to compile this:
>
> libstdc++-v3/libsupc++/new_opa.cc
>
> The error messages are as follows:
>
> new_opa.cc: In function 'void* operator new(std::size_t, std::align_val_t)':
> new_opa.cc:36:30: error: '_aligned_malloc' was not declared in this scope
> #define aligned_alloc(al,sz) _aligned_malloc(sz,al)
>
> new_opa.cc:103:33: note: in expansion of macro 'aligned_alloc'
>   while (__builtin_expect ((p = aligned_alloc (align, sz)) == 0, false))
>                                 ^~~~~~~~~~~~~
>
> new_opa.cc:36:30: note: suggested alternative: 'aligned_alloc'
> #define aligned_alloc(al,sz) _aligned_malloc(sz,al)
>                              ^
>
> new_opa.cc:103:33: note: in expansion of macro 'aligned_alloc'
>   while (__builtin_expect ((p = aligned_alloc (align, sz)) == 0, false))
>                                 ^~~~~~~~~~~~~
> My searches in the source code for _aligned_malloc found a
> changelog  entry for Bugzilla  PR libstdc++/79190, which is not for  Windows - it
> is for HP-UX 11.00.  I did see, however, in comment 6 of bug report
> 79190, the following reference to Windows:
>
> "We are using _aligned_malloc / _aligned_free on Windows, so it has to
> be the case that alignment matches in allocation and deallocation."
>
> There are no details about which kind of Windows gcc this is in (Cygwin?),  but
> this suggests that a fix for MinGW should be simple. I would like to be able
> to supply a fix for this before gcc 7 is released, but I don't know nearly enough
> about the details of how gcc is configured to do that before the release date.

According to the documentation, we may be missing a #include <malloc.h> in 
new_opa.cc, but if that's the case, it is strange that noone noticed 
before... Does adding this #include help?

-- 
Marc Glisse