[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

John McCall via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 22 11:28:41 PST 2021


On Mon, Nov 22, 2021 at 1:08 PM David Goldblatt via Phabricator <
reviews at reviews.llvm.org> wrote:

> davidtgoldblatt added a comment.
>
> (For background: I'm a jemalloc maintainer and wrote N2293).
>
> In D100879#3145361 <https://reviews.llvm.org/D100879#3145361>, @rjmccall
> wrote:
>
> > Platforms are permitted to make stronger guarantees than the C standard
> requires, and it is totally reasonable for compilers to assume that
> `malloc` meets the target platform's documented guarantees.  Arguably,
> libraries should not be replacing `malloc` if they fail to meet the
> platform's documented guarantees.
>
> I agree generally that assuming platform guarantees is reasonable for the
> compiler in targeting that platform, but I don't think I agree that the
> dlmalloc alignment is one of them.


Well, IIRC it's documented in the platform manual for `malloc`.  I suppose
one could argue that it's an implementation property which is only
guaranteed for unreplaced `malloc`s, but that's not what I would naturally
assume from reading the manual, and you'd think there would be a warning
that library code can only assume a weaker alignment.  I suppose you could
also argue that the manual itself is implementation-specific, but platform
guarantees have to be documented *somewhere*, and conventionally that's the
standard manual.

Still, if you can get glibc to confirm that the intent is that replacement
`malloc`s aren't required to provide the documented alignment, then I would
agree that Clang should not be assuming this alignment.

Supporting malloc replacement is a first-class feature for glibc malloc,


Again, this in itself doesn't mean much.  You are allowed to replace
`malloc`; you are not allowed to replace `malloc` with an incorrect
implementation.  Presumably we can agree that a replacement that only
provided 1-byte alignment would be wrong.  The standard for correctness is
defined by the platform.  If you replaced `malloc` with something that
returned 8-byte alignment on Darwin, you would definitely be wrong.  So
what you need here is a statement from the platform maintainers that it's
legal to replace `malloc` with something that provides less alignment than
is documented in `man malloc`.

Obviously, if you don't actually replace `malloc` and just provide a
`jemalloc` symbol, you can do whatever you want.


> and related projects avoid relying on alignment guarantees (e.g. libstdc++
> at one point considered assuming that 8-byte allocs were 16-byte aligned,
> and decided not to). At least one Linux distribution using clang (Alpine)
> uses musl, which is a weak-alignment implementation (contrary to what I
> claimed in N2293; I screwed up my background research).
>

If Alpine Linux wants to provide a weaker alignment guarantee than the
"standard" Linux platform, they're entitled to.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20211122/073bb0c0/attachment-0001.html>


More information about the cfe-commits mailing list