https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to pc from comment #5)
> The code will use malloc if it can, and posix_memalign otherwise.
If it knows it can based on some very simplistic criterion, yes. Is this
a useful optimisation, or is this premature optimisation?
> 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;
> --
If it does call malloc it *also* does this, it is just that __alignment
already is the same then (and this function does an early out, too) ;-)
> (I probably would've written the code slightly differently.)
Yeah.
> 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).
Likely, yes.
> All that being said, I'm not sure I see any problem with the code, and maybe
> the analyzer is being a bit overzealous?
That's my point, yes.
- * -
Ah. This is some 3rd party checker. Closing as INVALID.
