https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901
pc at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pc at gcc dot gnu.org
--- Comment #5 from pc at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #4)
> is this micro-optimisation useful at all, don't
> posix_memalign and malloc end up the same under the covers anyway?
posix_memalign returns memory aligned to a specified power-of-2 alignment.
malloc returns memory aligned to some ABI minimum. (You already know this, I'm
sure.) The code will use malloc if it can, and posix_memalign otherwise. There
may be a slight advantage to using malloc instead of posix_memalign. The paths
are indeed different. I'm not sure why the floor is raised after determining
not to call malloc:
--
if (__alignment == __malloc_align && __alignment == __vec_align)
return malloc (__size);
if (__alignment < __vec_align)
__alignment = __vec_align;
--
(I probably would've written the code slightly differently.)
It appears to me that the identified code would be always false on a 32-bit
system, where __malloc_align would be computed as 64 bits, and _vec_align as
128 bits. It would be always true on a 64-bit system (128 == 128).
All that being said, I'm not sure I see any problem with the code, and maybe
the analyzer is being a bit overzealous?
FWIW, the code was likely taken as an analog to gcc/config/i386/pmm_malloc.h:
--
if (__alignment == 1)
return malloc (__size);
if (__alignment == 2 || (sizeof (void *) == 8 && __alignment == 4))
__alignment = sizeof (void *);
if (posix_memalign (&__ptr, __alignment, __size) == 0)
return __ptr;
--
