<div dir="ltr"><div dir="ltr">On Mon, Nov 22, 2021 at 1:08 PM David Goldblatt via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">davidtgoldblatt added a comment.<br>
<br>
(For background: I'm a jemalloc maintainer and wrote N2293).<br>
<br>
In D100879#3145361 <<a href="https://reviews.llvm.org/D100879#3145361" rel="noreferrer" target="_blank">https://reviews.llvm.org/D100879#3145361</a>>, @rjmccall wrote:<br>
<br>
> 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.<br>
<br>
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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Supporting malloc replacement is a first-class feature for glibc malloc,</blockquote><div><br></div><div>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`.</div><div><br></div><div>Obviously, if you don't actually replace `malloc` and just provide a `jemalloc` symbol, you can do whatever you want.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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).<br></blockquote><div><br></div><div>If Alpine Linux wants to provide a weaker alignment guarantee than the "standard" Linux platform, they're entitled to.</div><div><br></div><div>John. </div></div></div>