[Bug target/104901] gcc/config/rs6000/mm_malloc.h:46: incorrectLogicOperator

["pc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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;
--