RFC: Over-aligned heap memory allocation

Keith Marshall <[email protected]> Mon, 20 Apr 2020 21:23:56 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
In mid-2018, David Gressett raised an issue, privately among the MinGW
developers, (of whom he is one, and thus he has access to their private
forum), relating to problems he was experiencing when building the Ada
component of GCC; specifically, the build configuration expected to link
with Microsoft's over-aligned heap allocator, but was unable to do so.

Investigation revealed that the GCC configuration process was finding a
reference to Microsoft's _aligned_malloc() in libmsvcrt.a, (it had been
added to MSVCRT.DLL, from Vista onward, which would have broken support
for legacy platforms, which MinGW still aims to accommodate); however,
having identified availability of the API, the GCC Ada implementation
was then found to be broken w.r.t. correct header inclusion, and even
w.r.t. feature test macro definitions being placed too late to have any
effect.  Nonetheless, identification of the issue prompted a review, and
ultimate rewrite, of the existing provisions within MinGW for support of
over-aligned heap memory allocation.  The outcome of that review may be
found at https://osdn.net/projects/mingw/ticket/38607.

It may be noted, from that ticket, that having corrected deficiencies of
the original MinGW over-aligned heap allocator API, I went on to propose
implementation of ISO-C11's aligned_alloc() function, (which contrary to
Microsoft's assertion, in their C++ language conformance document:

https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=vs-2019
> C11: The Universal CRT implemented the parts of the C11 Standard 
> Library that are required by C++17, with the exception of C99
> strftime() E/O alternative conversion specifiers, C11 fopen()
> exclusive mode, and C11 aligned_alloc(). The latter is unlikely to be
> implemented, because C11 specified aligned_alloc() in a way that's
> incompatible with the Microsoft implementation of free(): namely,
> that free() must be able to handle highly aligned allocation.

is actually quite trivial to implement), together with POSIX.1-2001's
posix_memalign() function, (which is equally trivial to implement).

At the time, I invited — on the ticket only — a peer review of the two
additional functions, and left it at that; to date, no one has taken me
up on that invitation.

Recently, this came to my attention again, on account of its relevance
to new ticket https://osdn.net/projects/mingw/ticket/40315.  As I have
noted on this new ticket, applying the <stdlib.h> patch to implement
ISO-C11's aligned_alloc() will also DTRT w.r.t. the GCC implementation
of C++17's std::aligned_alloc().  Consequently, I'd like to reiterate
the invitation for peer review, and extend it to the wider MinGW user
community; if no one offers a reasoned objection, by the end of April, I
would like to include the proposed implementations of aligned_alloc(),
and of posix_memalign(), in upcoming mingwrt-5.3.1.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc (application/pgp-signature, 833 B)