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. Supporting malloc replacement is a first-class feature for glibc malloc, 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). > With that said, it's probably not unreasonable for Clang to provide an option > that controls its assumptions about `malloc`. We should think somewhat > carefully about whether there are other behaviors we'd want to include in > that, though. This makes sense to me; this is broadly how clang handles `operator new` alignment as well. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100879/new/ https://reviews.llvm.org/D100879 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
