On Tue, Jul 21, 2020 at 7:24 AM Bruno Haible <br...@clisp.org> wrote: > > > Checkout https://forum.kde.org/viewtopic.php?p=66274 for some info on > > detection of posix_memalign. > > It's well-known that you can't use standards symbols like __STDC_VERSION__ > or _XOPEN_SOURCE for hardly anything. We wouldn't have hundreds of > AC_CHECK_FUNC calls in gnulib/m4/ if they weren't needed.
Lol... yeah. > > I think there's also another option, if interested. On x86 you can get > > aligned allocations with _mm_malloc. > > _mm_malloc is not in the libc of any system I know of. The docs [1] state > that it is a compiler built-in. If it relies on an Intel library, that > would make it unsuitable for use in gnulib (since it would introduce an > additional link dependency for something that should not need one). As far as I know it's part of any compiler that supports Intel processors with SSE. > > And with PPC you can get an > > aligned block with vec_malloc. > > On AIX, yes, not on Linux/PowerPC nor on Mac OS X/PowerPC. But the only > documentation of this function that I can find [2] is not a reference > documentation. Why would I use a function that has no reference documentation? To avoid that alternate code. > > As you probably know, Linux aligns heap allocations to 16 by default. > > It's the libc which does this, not the kernel. And glibc aligns malloc() > results to 8 bytes on most 32-bit platforms. I believe the runtime is required to return a pointer aligned for the largest C type on the system. On x86 that's 16 bytes due to the xmm datatypes. Jeff
