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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118804/new/ https://reviews.llvm.org/D118804 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits