Date: Sun, 10 Nov 2013 13:22:33 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Cc: Gregor Richards <gr@...due.edu> Subject: Re: Latest pkgsrc results [What builds on musl 0.9.13?] On Sun, Nov 10, 2013 at 06:14:13PM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@...ifal.cx> [2013-11-09 11:41:47 -0500]: > > On Sat, Nov 09, 2013 at 05:16:55PM +0100, Szabolcs Nagy wrote: > > > this is sad > > > so c++ code that includes mm_malloc.h and stdlib.h will fail > > > > What is mm_malloc.h and why is it declaring malloc itself rather than > > including stdlib.h? > > > > it declares posix_memalign and defined _mm_malloc and _mm_free > > i think it was added to gcc so it is possible to allocate memory > for the sse intrinsics with the right alignment (included in > xmmintrin.h which follows the intel and msvc api, see bug report) > > and for c++ they add throw() to posix_memalign so it's incompatible > with the libc one hence boost fails to build (or anythning that > uses both xmmintrin.h and stdlib.h) > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16570 I see. Well eseentially, the "linux" mm_malloc.h in gcc is glibc-specific, then. (BTW, if these prototypes are incompatible, I think it also means the glibc prototypes are non-conforming to the C++ standard, but that's an entirely separare issue.) I'm not sure what the proper fix is, though. Would declaring the extern function with scope local to the _mm_malloc function, rather than file scope, fix the problem? If so, that could probably be upstreamed in gcc. Another valid gcc-level fix would be: extern "C" int __gcc_posix_memalign (void **, size_t, size_t) __attribute__((__alias__("posix_memalign"))) throw (); I'm leaning towards considering this the superior fix, as it also avoids polluting the namespace with posix_memalign like gcc is currently doing. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.