[PATCH] D118804: Revert "[Clang] Propagate guaranteed alignment for malloc and others"
John McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Feb 8 10:21:26 PST 2022
rjmccall added a comment.
I'm not sure your new wording is any clearer; a
In D118804#3304337 <https://reviews.llvm.org/D118804#3304337>, @urnathan wrote:
> In D118804#3304280 <https://reviews.llvm.org/D118804#3304280>, @aaron.ballman wrote:
>> In D118804#3304261 <https://reviews.llvm.org/D118804#3304261>, @urnathan wrote:
>>> While C2X has blessed such smaller alignments, the x86_64 ABI (in particular), has not. However, using that ABI to justify 'It. Is. 16. Bytes.', is really an exercise in reality denial at this point. just thought I'd make it clear we have conflicting standards and practicality to attend to.
>> Do we want me to report back to WG14 with information that N2293 might not suitable for adoption into C2x?
> I think N2293 is fine for C2x. It is blessing an implementation of lower alignment allocations. Putting the programmer on notice that they can no longer assume some things.
> As a compiler I think we need to deal with the reality that there are non-ABI conforming [system-dependent] allocators out there, and not simply say 'But the ABI says ...'
If a platform's ABI guarantees something, and the platform's system allocator actually does it, then that's the required behavior there, and replacement allocators that don't live up to it are non-conformant. But if the system allocator intentionally *doesn't* do it, and the platform's ABI is a generic ABI, then yeah, we have to understand that as an intent to declare a platform-specific deviation from the generic ABI.
> There is already at least one thing the ABI says that is not valid on some systems [sret return behaviour and Swift], for equally good reasons. The compiler deals with that.
Can you explain what you mean here? Swift's conventions are not really bound by the C ABI.
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the cfe-commits